Date: Fri, 09 Apr 1999 06:12:00 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: xtc-devel: XTC development mailing list Just a short note/test message to let you all know that I've switched over to majordomo for the mailing list. Now people can subscribe and unsubscribe by themselves, and I can maintain an archive of messages easily (which I'll be making available on the website soon). Also, Robert Klein has send in a patch to get XTC to compile under Solaris. You can get it from ftp://ftp.area51.org.au/incoming/xtc/patch-0.1.2-rk1 I've made an /incoming/xtc directory on ftp.area51.org.au for anything you need to upload like patches, etc. That way everyone can get to them easily and we can avoid attachments on the mailing list. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. From: Robert Klein Date: Fri, 9 Apr 1999 09:54:09 +0200 (MET DST) To: xtc-devel@area51.org.au Subject: xtc-devel: XTC 0.1.2-rk1 patch problem Everyone who is trying my patch-0.1.2-rk1, please erase the -O2 options in the Makefile. It is causing the Linux version to segfault at startup. The Solaris version still segfaults. Looks like a problem with dir_get_path(), line 349 in dir.c. If you're lucky I'll have a patch after the weekend. Robert --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Fri, 09 Apr 1999 17:06:18 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC 0.1.2-rk1 patch problem I found this problem too. I've fixed it up and quite a number of others that pop up with the -Wall option. I'm in the process of merging your changes into what will be 0.1.3 (as there are a few other things that I have added since 0.1.2 as well) and I will probably have it out tonight, if not tomorrow. Robert Klein wrote: > > Everyone who is trying my patch-0.1.2-rk1, please erase the -O2 > options in the Makefile. It is causing the Linux version to > segfault at startup. > > The Solaris version still segfaults. Looks like a problem with > dir_get_path(), line 349 in dir.c. If you're lucky I'll have a patch > after the weekend. > > Robert > --- > For more info on XTC, visit http://www.area51.org.au/xtc > To unsubscribe from this list, send a message to > majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the > message body. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Fri, 09 Apr 1999 19:29:16 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: xtc-devel: XTC version 0.1.3 0.1.3 is up. You can grap it from ftp://ftp.area51.org.au/pub/xtc/xtc-0.1.3.tar.gz I've incorporated Robert's changes into this version. It turns out that the coredumps he was having were due to the fact that dir_get_path had no return statement in it. Somehow the path was getting returned before, but probably because it was in just the right place in memory or something. After the optimisations were turned on with -O2, that wasn't the case. That's all fixed up now, so you can use optimisation :) I also added the -Wall option to gcc. This gave me a lot of errors when I tried to compile, but they were all minor things like unused variables, etc. so I've cleaned all of those up. This version should compile under Solaris now, provided you have ncurses. There's a bit of a problem with define_key() which is used in main() - this is an ncurses specific extension and I don't think it's available in all versions of ncurses. If you know which is the first version of ncurses to use it, let me know. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sat, 10 Apr 1999 08:22:10 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: xtc-devel: Re: XTC 0.1.3 Mathias Winkler wrote: > New command in 0.1.3 ALT-'M'ove to move directories should be > rather: ALT-'G'raft to match XTree terms There are a couple of reasons for this - One is that I intended to use ALT-G for chGrp branch (as with ALT-O for chOwn branch and ALT-H for cHmod branch). The other is that I decided that "move" was a much better word for this, as "graft" would be considered a rather strange term for what is commonly known as move. A bit of history here: If I remember rightly, moving directories in DOS was not a common operation. There was no DOS command to do this until version 5 or 6 I think, and Xtree moved (or "grafted") directories by manipulating the filesystem directly rather than using proper calls. This was evidenced by the fact that you couldn't graft on a network drive, and when you attempt to do this under Win95, windows warns you that the program is trying to access the disk directly. I realise it's straying a bit from the original version, but it seems more logical. What do you guys think about this? Sould it be "Graft" or "Move"? > Also, > include > include > in common.h > doesn't compile under my Linux until I change back to > include > include Robert suggested I put ncurses/ in front of those includes so it was easier to determine which package provided them. Maybe what we should do is this: #include #include /* from ncurses */ This makes it fairly obvious and should avoid these compile problems. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sat, 10 Apr 1999 14:29:37 +0200 (MEST) From: Mathias Winkler To: xtc-devel@area51.org.au Subject: Re: xtc-devel: Re: XTC 0.1.3 > Mathias Winkler wrote: > > > New command in 0.1.3 ALT-'M'ove to move directories should be > > rather: ALT-'G'raft to match XTree terms > > There are a couple of reasons for this - One is that I intended to use ALT-G for > chGrp branch (as with ALT-O for chOwn branch and ALT-H for cHmod branch). The > other is that I decided that "move" was a much better word for this, as "graft" > would be considered a rather strange term for what is commonly known as move. > > [...] > > I realise it's straying a bit from the original version, but it seems more > logical. What do you guys think about this? Sould it be "Graft" or "Move"? Well, so why don't we rather use "F6" as a key for "moving" directories??? That would be compatible to the Midnight Commander, at least. Sorry, if I get cynical, but, forgive me, I thought XTC should be an *XTree_clone*, rather than an "XTree-like" file manager for Unix !!?? Moreover, chGrp is obviously not an DOS-XTree command, but this should mean to find a hotey *not* used for other commands in DOS-XTree for it !! Making a close XTree clone does only make sense if we keep the hotkey "as_close_as_possible" to the original ! Peter, you said, your goal is to write a great XTree clone for Unix similar to the great XTree clone for Win9x/NT ZTreeWin. The latter *is* keeping as close as possible to the model, and if it adds new commands, they all do use hotkeys not yet provided with XTree, so why doesn't XTC ??? Rgds Mathias -- mathias winkler - muenchen/munich, germany mailto:mat.winkler@arkanda.net You are welcome to visit my * XTree Fan Page * at: http://xtfp.arkanda.net --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sat, 10 Apr 1999 17:25:23 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: Re: XTC 0.1.3 Mathias Winkler wrote: > > I realise it's straying a bit from the original version, but it seems more > > logical. What do you guys think about this? Sould it be "Graft" or "Move"? > > Well, so why don't we rather use "F6" as a key for "moving" directories??? > That would be compatible to the Midnight Commander, at least. > Sorry, if I get cynical, but, forgive me, I thought XTC should be an > *XTree_clone*, rather than an "XTree-like" file manager for Unix !!?? > > Moreover, chGrp is obviously not an DOS-XTree command, but this should mean > to find a hotey *not* used for other commands in DOS-XTree for it !! > > Making a close XTree clone does only make sense if we keep the hotkey > "as_close_as_possible" to the original ! Peter, you said, your goal is to > write a great XTree clone for Unix similar to the great XTree clone for > Win9x/NT ZTreeWin. The latter *is* keeping as close as possible to the > model, and if it adds new commands, they all do use hotkeys not yet > provided with XTree, so why doesn't XTC ??? Fair comment, I see your point ;) Thinking about it again, I agree with you. I think a good solution to the chgrp problem is the one you mentioned earlier, that is, having the chown, chgrp and chmod functions accessed from the Attributes command, which I guess they are suited more there than in the main set of commands. This will be more in keeping with XTree for UNIX and XtreeNet. Then we could have both ALT-G and ALT-M bound to it (ALT-M isn't used at all in the original). -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. From: "C. R. Bryan III" To: xtc-devel@area51.org.au Date: Sat, 10 Apr 1999 13:44:44 -0400 Subject: Re: xtc-devel: Re: XTC 0.1.3 > > Mathias Winkler wrote: > > > > > New command in 0.1.3 ALT-'M'ove to move directories should be > > > rather: ALT-'G'raft to match XTree terms > > > > There are a couple of reasons for this - One is that I intended to use ALT-G for > > chGrp branch (as with ALT-O for chOwn branch and ALT-H for cHmod branch). The > > other is that I decided that "move" was a much better word for this, as "graft" > > would be considered a rather strange term for what is commonly known as move. > > > > [...] > > > > I realise it's straying a bit from the original version, but it seems more > > logical. What do you guys think about this? Sould it be "Graft" or "Move"? > ---x--- > > Making a close XTree clone does only make sense if we keep the hotkey > "as_close_as_possible" to the original ! Peter, you said, your goal is to > write a great XTree clone for Unix similar to the great XTree clone for > Win9x/NT ZTreeWin. The latter *is* keeping as close as possible to the > model, and if it adds new commands, they all do use hotkeys not yet > provided with XTree, so why doesn't XTC ??? > > Rgds > Mathias I'm with Mathias on this. At least at first, we should strive for key- compatibility with XTG3.01 for console use. Variations and expansions are best handled as an Alt-F10 configuration option. I recall the transition from XTG1.4 to XTG2.0 (I think that's when it happened) when branch mapping and collapsing went in, and the [-] and [+] keys were reassigned to [<] and [>], and if you wanted it the old way you had to give it a command-line switch. That got annoying really fast. You couldn't make the change permanent, you had to set up a BATfile to run XTG to feed it that switch (along with switches for "quit without asking" and "edit without asking"). I suggest instead that a text config file be used for key bindings, perhaps a separate one from the main configuration file, read in at startup, and that key mapping be taken from that. The Alt-F10 configuration tool should modify the config files, with simple menu selections for modifying groups of key bindings (for getting around the Alt keys not working through a telnet connection, and other such limitations), with a reinit when it's dismissed so the changes get read in. Until the Alt-F10 configurator is written, those text config files can be modified by hand, thus everybody is happy. I'm doing that kind of this in Perl already for HTML page generation, using a config line format of: KEY=keyvalue and splitting at the first '=', and it runs reasonably quickly, considering it's Perl. If Alt-F10 shells out to a Perl script for now, we can modify the configuration menus quickly while major changes are being made in the main program, rewriting it to C (I've got canned code for that already, it's not that hard to modify for this project) when things stabilize. The major hassle at this point will be redoing the key command inputs now to map through structs loaded at startup, but it looks like that's where XTC needs to go anyway, for reasons of adaptation to different consoles. The editor Joe (or the jstar variation that I prefer) has a good model for such a key-binding config in its joerc, using symbolic names for operations. Hmm, maybe that's where I should focus my efforts.. C. R. Bryan III crb3@computer.org crb3@stormbringer.org --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 11 Apr 1999 13:52:13 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: xtc-devel: Key bindings In response to the recent discussion about key bindings, here is my suggestion about what we should do: Follow key bindings as closely as possible to the original. Provide alternate keys for CTRL and ALT (perhaps F3 and F4, or ` and TAB) for those using terminals (as opposed to the Linux console). This will mean for example that move tagged will be CTRL-M, but if you're on a terminal you will have to use F3 then M (as CTRL-M would be interpreted as ENTER). But CTRL-D and CTRL-L will work anywhere. ESC will be cancel, and on a console you will get an instant response but on a terminal you will get a 1/2 second delay, but you can use F10 instead if you want. Extra functions that were not in the dos version are added and always available (without turning on special options) but use only keys that were not used in the original. I think this way we can keep close to the original but also accommodate terminals conveniently, while keeping the configuration simple. What does everybody think about being able to alter key bindings? I know this is a feature available in a lot of UNIX programs, but I'm wondering how useful it really is. I realise it gives a lot more power to customize a program, but do you think a lot of people will use this? I generally find that once I learn a program's keys I am comfortable using them without wanting to change them. Oh, except vi ;) -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 11 Apr 1999 22:08:38 +0200 (MEST) From: Mathias Winkler To: xtc-devel@area51.org.au Subject: Re: xtc-devel: Key bindings On Sun, 11 Apr 1999, Peter Kelly wrote: > Follow key bindings as closely as possible to the original. Provide alternate > keys for CTRL and ALT (perhaps F3 and F4, or ` and TAB) for those using F3 and F4 keys are a very good idea for some reasons: - XTreeGold uses the F4 key to toggle between the Ctrl-,Alt- and the standard menu!) - The (unshifted) F3 key in the standard menu is totally *unused* in XTreeGold - xtree for UNIX Systems uses the same keys, namely F3 to substitute CTRL, and F4 to substiture Alt, if these shouldn't work with the respective console. > Extra functions that were not in the dos version are added and always available > (without turning on special options) but use only keys that were not used in the > original. > > I think this way we can keep close to the original but also accommodate > terminals conveniently, while keeping the configuration simple. Absolutely, I'm very happy to hear this, of course agreeing, this is exactly what an XTree-*clone* should go like! (And ZTreeWin, for example, does - and now XTC also does -great!). > What does everybody think about being able to alter key bindings? I know this is > a feature available in a lot of UNIX programs, but I'm wondering how useful it > really is. [...] Agreed, again, IMHO the most important strenght of an XTree clone does result from the fact that all those people used to hit those familiar XTree-key-combinations blindly and "while in sleep" ;-) immediately feel "at home" with such an XTree clone. Being able to randomly alter hotkey-binding would certainly produce rather much of confusion, I think. The only keys making sense to offer an user-customizable binding are those modifier-keys like CTRL- and ALT, of course, because they are much more non-standard in the world of UNIX machines than they are now in the Wintel-World. Rgds Mathias -- mathias winkler - muenchen/munich, germany mailto:mat.winkler@arkanda.net You are welcome to visit my * XTree Fan Page * at: http://xtfp.arkanda.net --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. From: Robert Klein Date: Fri, 16 Apr 1999 10:43:46 +0200 (MET DST) To: xtc-devel@area51.org.au Subject: xtc-devel: XTC compat / coding issues Hi, I'm onto several things today, forst is the level of compatibility to XTG/ZTB/ZTW (My first real exposure to XTree was ZTree Bold). (I think I lost one of the key-binding mails, so please accept my apologies for repetitions). I think the chmod/chgrp/chown commands should be available under Attributes. (How important is is the Avail command? I don't have a small quota, so it's unlikely I'll ever use it, how was your usage under DOS/win/OS/2? I don't like the idea of sacrifying it for a directory Attributes function while this seems prudent to get interface consistency.) Most likely we'll need an Hide/unHide command not only for directories, but for files as well, as Unix tenda to accumulate lots of .config files. A Log command shoud be introduced, either via predefinded "drive letters" in a .xtcrc file, or by entering the base point. (I cannot get into my home directory at university, because xtc gets lost somewhere in afs.) This option should include that the parent directory of a base point is _never_ even examined when you are on that 'drive.' Should symlinked directories shown as directories? I think that's a yes. Peter, could you include the xtc_map.txt file in the distribution. Also, do you have a preferred coding style? (e.g. the Linux Kernel CodingStyle file?) I'd like one to be included in the distribution as well. OK, now comes the complicated part. What do you think of XTC being capable of being used for remote filesystems too (e.g. ftp://ftp.area51.org.au/)? This would require to separate the execution unit from the User interface unit, make lists of available commands and so on. A first step to this approach would be to call functions via pointer, e.g. we have pointers to a local_file_rm function and a ftp_file_rm function, using whatever is appropriate. Something like (in babies C): enum filesystem_type {local, ftp, zip, targz, tar}; Switch base-point(filesystem_type) { load_functions(filesystem_type) ... } Enough of the rant! I hope to get my hands on a decent book about POSIX compatible programming these days. Perhaps I'll can do some more helpful (i.e. programming) then ;-) regards, Robert --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Fri, 16 Apr 1999 18:34:05 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC compat / coding issues Robert Klein wrote: > > Hi, I'm onto several things today, forst is the level of compatibility > to XTG/ZTB/ZTW (My first real exposure to XTree was ZTree Bold). > (I think I lost one of the key-binding mails, so please accept my > apologies for repetitions). > > I think the chmod/chgrp/chown commands should be available under > Attributes. (How important is is the Avail command? I don't have a > small quota, so it's unlikely I'll ever use it, how was your usage under > DOS/win/OS/2? I don't like the idea of sacrifying it for a directory > Attributes function while this seems prudent to get interface > consistency.) I agree with this. I mentioned the other day that I thought this should be under the Attributes command, as there a couple of key conflicts in with ch* and it is more in keeping with the way it was done in XTree for UNIX system and XTreeNet. Perhaps the key combination could be CTRL-A. As Mathias pointed out earlier, if we're going to make clone, it should be as close as possible to the original. There are a number of key bindings in the original I don't agree with, but many people (including myself) are used to them, so changing them means that many hard-core XTree fans will be alienated by a program that's not the "real thing". But we need to find a way to work in these extra features around those. I'd like to have functions for manipulating a whole branch of directories as well, like copy branch, graft (which we already have), and chown/chgrp/chmod (attributes now). ALT-G is graft, I was thinking possibly ALT-A for attributes (of the whole branch, that is) but unfortunately C and ALT-C are already taken in the directory for compare dir/compare branch. > > Most likely we'll need an Hide/unHide command not only for directories, > but for files as well, as Unix tenda to accumulate lots of .config > files. Perhaps, but I'm not sure this is quite as relevant under UNIX as it was in DOS. Most of the time these files are generated or used by programs who expect them to have this name, and changing them is only useful if you are viewing the directory listing without showing hidden files, and even then they probably won't be useable by those programs because of the name change. > > A Log command shoud be introduced, either via predefinded "drive letters" > in a .xtcrc file, or by entering the base point. (I cannot get into > my home directory at university, because xtc gets lost somewhere in > afs.) This option should include that the parent directory of a base > point is _never_ even examined when you are on that 'drive.' I'd like to do this, but I'm not sure how it should work. Traditionally in DOS of course, the trees you'd see on different logged drives were completely separate, unless you were using a SUBSTed drive multiple network drive mappings to different parts of a network volume. You could have a situation where you have, say, your home directory logged and the root directory logged, but if you change something in your home directory, does the tree with the root dir at it's base get updated, and vice versa? Of course, this command would be necessary if we implement Midnight Commander-style virtual filesystems like ftp, rpms and archives as you suggested below. > > Should symlinked directories shown as directories? I think that's a yes. This would also be good, however, I can see a few problems with doing this also :( For example, say, logging an entire /usr branch would give you 3 copies of your X11R6 directory - /usr/X11R6, /usr/X11, /usr/X386 (at least that's how it's setup on my RedHat system). Say you do that and then do a branch (B) command, and you'll get 3 copies of each file in the listing. But if you tag one of them do the others get tagged? What about if you then do a copy with paths to somewhere... do you get 3 copies of the files, or one copy and two links, or just one copy (in which case which directory does it go in)? > > Peter, could you include the xtc_map.txt file in the distribution. Also, Sure. > do you have a preferred coding style? (e.g. the Linux Kernel CodingStyle > file?) I'd like one to be included in the distribution as well. Well, the only thing I *really* find that I need when I'm coding is the /*********/ style lines at the start of each function (in perl I use #################). This way, I find it much easier to see where functions start when I'm quickly scanning through code. Pretty much all other C code I've looked at doesn't have this but I can't understand why. Maybe Emacs has some special feature which will hilight function headers or something. I don't use it so I don't know. CRB puts the function name plus a . as a comment in the header so you can search for function_name. in your editor and go straight to the function itsself, rather than other references to it. I should probably use this too. About the only thing I follow in the Linux coding style (in /usr/src/linux/Documentation/CodingStyle, for others reading this that don't know about it) is the K&R braces. Tabs: I don't use tabs at all. I *really* should. Unfortunately once you get into a habbit like this, it hard to get out of :( but I'll try. One day I'll have to go through all the code and fix this up. Maybe (actually, DEFINETLY) I'll use need to use a perl script for this. Indentation: I generally prefer two spaces. Some of the functions I write (e.g. file_window_chmod_tagged) tend to get quite deep in loops, conditionals, etc and using 8 or even 4 would wear out the horizontal scrollbar on most editors. And the lines themselves are often long because I sometimes I use long function and variable names. I don't find it difficult to read. Perhaps the author of CodingStyle should consider taking breaks more often :) > > OK, now comes the complicated part. What do you think of XTC being > capable of being used for remote filesystems too (e.g. > ftp://ftp.area51.org.au/)? This would require to separate the execution unit > from the User interface unit, make lists of available commands and so on. > A first step to this approach would be to call functions via pointer, > e.g. we have pointers to a local_file_rm function and a ftp_file_rm > function, using whatever is appropriate. Something like (in babies C): > > enum filesystem_type {local, ftp, zip, targz, tar}; > Switch base-point(filesystem_type) > { > load_functions(filesystem_type) > ... > } Yes, I'd always thought this would be a good idea to implement in the future. It'll take a bit of thinking about, but I'm sure we'll be able to do it. > > Enough of the rant! I hope to get my hands on a decent book about POSIX > compatible programming these days. Perhaps I'll can do some more > helpful (i.e. programming) then ;-) > > regards, Robert > > --- > For more info on XTC, visit http://www.area51.org.au/xtc > To unsubscribe from this list, send a message to > majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the > message body. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. From: Robert Klein Date: Tue, 13 Apr 1999 13:40:56 +0200 (MET DST) To: xtc-devel@area51.org.au Subject: xtc-devel: patch-0.1.4-rk1 I just uploaded my 0.1.4-rk1 patch into the incoming directory. Differences to the vanilla 0.1.4 are: - added support for HP-UX 10 and Digital Unix V4 - fixed compile problems on Solaris Problems: - segfaults on DUX4 when trying to navigate with cursor keys. Does anyone of you use C386? I like its concept of warnng levels which IMO is much better than gccs. I'm still having problems getting it installed. (Perhaps it is time to get my trusty old Sinclair QL back out from storage ;-) Robert --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Tue, 20 Apr 1999 00:45:56 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: xtc-devel: area51.org.au back online Hello everyone, just thought I'd let those of you who have been trying to access the site in the past couple of days or send mail to the list that area51.org.au is back online. >From now on, there will be no /incoming directory on the FTP site, so if you need to send in patches please email them to me (not to the list) and I'll put them up myself. I'll leave the reasons for this up to your imagination, but I'll just suggest to you all to make sure your systems are kept up to date :( -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. From: Robert Klein Date: Tue, 20 Apr 1999 14:06:42 +0200 (MET DST) To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC compat / coding issues [Attributes issue deleted.] >> Most likely we'll need an Hide/unHide command not only for directories, >> but for files as well, as Unix tenda to accumulate lots of .config >> files. > > Perhaps, but I'm not sure this is quite as relevant under UNIX > as it was in DOS. > Most of the time these files are generated or used by programs > who expect them > to have this name, and changing them is only useful if you are viewing the > directory listing without showing hidden files, and even then they probably > won't be useable by those programs because of the name change. Sorry, I did not make myself clear enough. What I wanted to imply is that someone might want to reconfigure his system and then needs massive viewing/editing of .rc files _and_ directories (.netscape, .tin,...). BTW, a standard editor/viewer should be set in a .xtcrc file, e.g. edit pico view pico -v (no, I use vi and emacs.) >> A Log command shoud be introduced, either via predefinded "drive letters" >> in a .xtcrc file, or by entering the base point. (I cannot get into >> my home directory at university, because xtc gets lost somewhere in >> afs.) This option should include that the parent directory of a base >> point is _never_ even examined when you are on that 'drive.' > > I'd like to do this, but I'm not sure how it should work. > Traditionally in DOS > of course, the trees you'd see on different logged drives were completely > separate, unless you were using a SUBSTed drive multiple network > drive mappings > to different parts of a network volume. You > could have a situation where you > have, say, your home directory logged and the > root directory logged, but if you > change something in your home directory, does > the tree with the root dir at it's > base get updated, and vice versa? We would need something like the AFS callback method to keep AFS-cache up-to-date. I imagine something like this: log(path) { add_to_list(list xtc_basepoints, path) ... } And whenever you perform an operation you must: perform(operation) for (i in xtc_basepoints) if chk_if_part_of(i, operation_path) update(operation_path) You could group operations in one directory together and then update. >> Should symlinked directories shown as >> directories? I think that's a yes. > > This would also be good, however, I can > see a few problems with doing this also > :( For example, say, logging an entire > /usr branch would give you 3 copies of > your X11R6 directory - /usr/X11R6, /usr/X11, > /usr/X386 (at least that's how it's > setup on my RedHat system). Say you do > that and then do a branch (B) command, > and you'll get 3 copies of each file in > the listing. But if you tag one of them > do the others get tagged? What about if > you then do a copy with paths to > somewhere... do you get 3 copies of the > files, or one copy and two links, or > just one copy (in which case which > directory does it go in)? GRRR! You may right. One option: Show 'em as directories, which one can not enter, but (L)og as (S)ymlink. Another: Just do it. If you tag one, just that is tagged (i.e. the X11/... symlink or the X386 symlink or the file under X11R6). You can at least delete a symlink without affecting the original file! If I copy something I get, what I copied. If I copy a symlink then I'll get a symlink. (That is copying with -d option. When you copy whole paths this seems to be a reasonable default anyway. While I might be missing some reason I think no-one wants to clutter up his disks ;-) ) To be frank (though my name is Robert -- I know this is an old joke...) I'd prefer _both_ options, the second perhaps as a .rc-file option. I talked with my brother the weekend, and he suggests not to omit the Open command (it is _not_ like eXecute as it starts an application according to file endings whereas eXecute only starts an executable. Robert --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Wed, 21 Apr 1999 10:22:19 +0000 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC compat / coding issues Robert Klein wrote: > > [Attributes issue deleted.] > > >> Most likely we'll need an Hide/unHide command not only for directories, > >> but for files as well, as Unix tenda to accumulate lots of .config > >> files. > > > > Perhaps, but I'm not sure this is quite as relevant under UNIX > > as it was in DOS. > > Most of the time these files are generated or used by programs > > who expect them > > to have this name, and changing them is only useful if you are viewing the > > directory listing without showing hidden files, and even then they probably > > won't be useable by those programs because of the name change. > Sorry, I did not make myself clear enough. What I wanted to imply is > that someone might want to reconfigure his system and then needs > massive viewing/editing of .rc files _and_ directories (.netscape, .tin,...). By hiding/unhiding, do you mean changing the name of the file (by adding/removing the trailing period) or by configuring XTC to either display or not display files/directories with that start with a period? > > BTW, a standard editor/viewer should be set in a .xtcrc file, e.g. > edit pico > view pico -v > > (no, I use vi and emacs.) One of these days I'll get round to including some configuration options. I hope eventually to have a configuration menu like XTree's, so that users don't need to edit the file by hand. The configuration file part would not be difficult to implement right now, but the menu-style configuration program would take a bit of work although it doesn't have do be done right away. One issue I was thinking about was having a system-wide and user-specific configuration files (I think Pine does this). Any settings specified in /etc/xtcrc would be the defaults for the system and could be maintained by the system administrator, while users could set specific options that differed from these in ~/.xtcrc However, this makes the menu-based configuration more complex. On the user side of things, for each setting, you would need a "system default" option. This is fairly easy to do, however what happens when the administrator is running the program? When they change a setting, does this get set in the system wide configuration or just root's configuration? I'm not quite sure how we would handle this. Perhaps it would just be easier to only use one configuration file, and then if there is to be a system-wide configuration, it could be placed in a publicly-accessable place like /etc and then symlinked to users dirs as .xtcrc, and if a user wants his/her own configuration, then they just make a copy of the file and use that. > We would need something like the AFS callback method > to keep AFS-cache up-to-date. > I imagine something like this: > > log(path) > { > add_to_list(list xtc_basepoints, path) > ... > } > > And whenever you perform an operation you must: > > perform(operation) > for (i in xtc_basepoints) > if chk_if_part_of(i, operation_path) > update(operation_path) > > You could group operations in one directory together and then > update. Another possible way to do it would be to use the same data structures for each logged branch, but have the tagged/non-tagged status of files stored separately. This way they are kept consistent automatically. > > >> Should symlinked directories shown as > >> directories? I think that's a yes. > > > > This would also be good, however, I can > > see a few problems with doing this also > > :( For example, say, logging an entire > > /usr branch would give you 3 copies of > > your X11R6 directory - /usr/X11R6, /usr/X11, > > /usr/X386 (at least that's how it's > > setup on my RedHat system). Say you do > > that and then do a branch (B) command, > > and you'll get 3 copies of each file in > > the listing. But if you tag one of them > > do the others get tagged? What about if > > you then do a copy with paths to > > somewhere... do you get 3 copies of the > > files, or one copy and two links, or > > just one copy (in which case which > > directory does it go in)? > > GRRR! You may right. > > One option: > Show 'em as directories, which > one can not enter, but (L)og as (S)ymlink. > > Another: > Just do it. If you tag one, just that is tagged > (i.e. the X11/... symlink or the X386 symlink > or the file under X11R6). You can at least delete > a symlink without affecting the original file! > If I copy something I get, what I copied. If I > copy a symlink then I'll get a symlink. > (That is copying with -d option. When you copy > whole paths this seems to be a reasonable default > anyway. While I might be missing some reason I > think no-one wants to clutter up his disks ;-) ) When copying with paths, say for example the whole /usr directory, you would most likely want it as it is, with one copy of the X11R6 directory, then the X11 and X386 links to it. If you're doing a copy with paths, and they don't already exist, then you can create those links, but they may already exist in which case you have a problem. Also, it's somewhat confusing having multiple copies of the same file in the listing. A user might think that they have two copies of a file, and then delete one, and then find out the other is gone as well. One possibility would be to display it in the tree, but as soon as the user tries to "enter" the directory, they are automatically transported to the real location of the directory. However, even this does not fit in well with the idea of logging an entire branch, and it could interrupt scrolling down one by one looking in directories. > I talked with my brother the weekend, and he suggests > not to omit the Open command (it is _not_ like eXecute > as it starts an application according to file endings > whereas eXecute only starts an executable. Ok, I didn't realise this. In that case it could be really useful, esp. when running under X - opening a html file will load it in netscape, opening a ps file will load ghostscript, etc. Good idea. O is free now as I've moved chown/chgrp/chmod into the "Attributes" command (will be in 0.1.6.... expect this soon) so we can do this. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. From: "C. R. Bryan III" To: xtc-devel@area51.org.au Date: Wed, 21 Apr 1999 08:55:49 -0400 Subject: Re: xtc-devel: XTC compat / coding issues > > > > BTW, a standard editor/viewer should be set in a .xtcrc file, e.g. > > edit pico > > view pico -v > > > > (no, I use vi and emacs.) > > One of these days I'll get round to including some configuration options. I hope > eventually to have a configuration menu like XTree's, so that users don't need > to edit the file by hand. The configuration file part would not be difficult to > implement right now, but the menu-style configuration program would take a bit > of work although it doesn't have do be done right away. > > One issue I was thinking about was having a system-wide and user-specific > configuration files (I think Pine does this). Any settings specified in > /etc/xtcrc would be the defaults for the system and could be maintained by the > system administrator, while users could set specific options that differed from > these in ~/.xtcrc > > However, this makes the menu-based configuration more complex. On the user side > of things, for each setting, you would need a "system default" option. This is > fairly easy to do, however what happens when the administrator is running the > program? When they change a setting, does this get set in the system wide > configuration or just root's configuration? I'm not quite sure how we would > handle this. > > Perhaps it would just be easier to only use one configuration file, and then if > there is to be a system-wide configuration, it could be placed in a > publicly-accessable place like /etc and then symlinked to users dirs as .xtcrc, > and if a user wants his/her own configuration, then they just make a copy of the > file and use that. > my opinions: When the root user goes into the config menu, they get a choice up- front: config personal or systemwide settings? systemwide settings go into something like /etc/.xtcrc. personal settings go in HOME/.xtcrc or /root/.xtcrc. A default .xtcrc is put into /etc/.xtcrc by the make:install process. if you delete it, the program will use the compiled internal defaults instead. When a user launches XTC, it looks for .xtcrc, first in the local directory (if nonroot or if 'ignore cwd config' is switched off), then in HOME directory (or /root, if root user), then in /etc. When a nonroot user goes into the config menu, the initial settings shown are what the program is currently using, from wherever it got them, and any changes cause it to write a full HOME/.xtcrc. If there are security settings which need to be kept out of the nonroot user's hands (show dotfiles, etc), we can reverse the nonroot startup so that it looks first at the global settings, then masks in the user's local settings for all non-security settings. I don't see that as useful yet; linux already does what's required to keep dangerous or inappropriate tools out of the hands of nonroot users, and the rest can be handled by compile-time options and the 'propagate' option discussed below. the config menu (Alt-F10) can start out as a perl script for the sake of flexibility and speed, being converted to C when things have pretty much settled down. Either way, the program should shell out to it just as in XTG. the config file should be in TAG=ARGUMENT format, perhaps with *.ini- style [section landmarks] if required, for ease of editing. that format also makes it real easy to process in perl using 'split'. it's easy to process in C too, but the speed bonus is needed in perl. if processing such a config file takes too long at each startup, then (preferred) have the startup code "compile" that config into a binary object (HOME/.xtcrc.bin) suitable for reading into a unioned struct, and have it do the compile only if the .bin is older than the text config (or absent), or if the .bin fails a checksum test. that way, current user-ordered settings are always used but the program doesn't suffer a time penalty unless there's a change. the "compiler" itself can be a shelled subprogram as long as it uses the same header files, enums and defines as the main program, for the sake of innately identical binary definition and placement. it also can start out as a perl script, processing the relevant *.h headers as input files while development is underway, then be hand- converted to C (or put into the MAKE stream and converted to emit the C source or headers for its compiled replacement) when things are settling down. if there's no text .xtcrc to be found in the system anywhere (root deleted /etc/.xtcrc and current user didn't generate one yet), the startup should copy out the compiled defaults as HOME/.xtcrc.bin to avoid the time penalty of the search. if the config menu script finds no text .xtcrc anywhere and changes are ordered, it should shell out to a script that generates a default one in the local directory by decompiling the .xtcrc.bin before proceeding with the edit. again, when the program is nearing version 1.0, perl scripts should be replaced with C so the final user isn't required to have perl installed. all such scripts should reside in XTC's installed home directory and be invoked with hardcoded strings, for security. One more nicety should keep everybody on the end-user side of things happy: when the root user chooses to edit the systemwide settings, an additional menu choice shows up in the final menu along with "save settings to disk" and "abandon changes": "save and propagate changes to all users". the config should keep a list of what tags have been edited, and this menu option causes it to walk the /home/* directory tree (plus /root) looking for /home/*/.xtcrc and modifying each as found to put the changed settings in where they'll be compiled to .xtcrc.bin the next time the local user runs XTC. this propagation process should remain an independently compiled/scripted program, chown root chmod 500, whose input is an "xtc.changed" text list of tags, so it can be run from a script (for sysadmin work) as well as shelled from the main ALT-F10 config process. Those are my thoughts on the matter, anyway. --cr --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Wed, 21 Apr 1999 23:38:39 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC compat / coding issues On the config file format: I think that having an INI-style format is a good idea. I've seen it used alot in windows programs (although not as much these days because of the registry) but not much in UNIX programs. However, it's a good, easy to understand file format. On compiling the config file: I doubt this would be necessary. Parsing a small text file shouldn't be too complex a process, and I'm sure that any machine will be able to handle it without any trouble. Many other UNIX programs (like Pine) do this and it's not a problem. Plus, dealing with the compile process is extra effort and complexity, and having to have the define files and header files around is messy, plus there's yet another . file in the user's directory. XTree stores it's configuration in a binary file format, it may or may not be because of speed. XTree used to run ok on my 4.7Mhz 8088..... if XTC doesn't run smoothly on any half-decent machine that's in use today then something's wrong :) On system-wide and user-specific settings: I like the idea of the sysadmin having a choice of editing system wide or user specific options when entering the menu, and general users just getting the user specific menu. This saves extra complexity in the configuration menu having to display what the system and user setting is for each option. For users, though, I think it might be useful to display the "actual configuration", that is, the program defaults, plus whatever the sysadmin has set, plus whatever they have set. This will make it simpler in that they don't have to worry about where the options are set, and then if something is not set to what they would like they can change it without having to be concerned with what the system default is. Only the options they have specifically set will then be stored in their own configuration file. Perhaps the users who can access the system-wide configuration could be determined by whoever has write access to /etc/xtcrc. Normally of course this will only be root, but it just adds a little bit of flexibility for other users to have control over it, as decided by root. If they have write access to the file, they can change it anyway with a text editor, so they might as well be able to do it in the program. On the propogation of settings to individual config files: This is a bad idea, IMHO as it is inefficient and potentially time/resource consuming, especially in the case where you have hundreds or perhaps thousands of users on the system, potentially with home directories on different NFS mounted drives. Changing a simple setting could mean scanning lots and lots of directories, possibly automounting a number of mounts, etc. where it may be the case that only 5 or 6 users actually have .xtcrc in their home directory. I think that having a system defaults file, and letting users change their personal settings if they wish would be quite sufficient. On the name of the config file: /etc/xtcrc would probably be better than /etc/.xtcrc. I have never seen a . file in /etc, I think the trailing periods on configration files are just so people don't have to look at them when viewing the contents of their directory. xtcrc is a file you normally want to see in /etc along with all the other system configuration files. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 16 May 1999 18:54:59 +0200 (MET DST) From: Dimitri Ars To: xtc-devel@area51.org.au Subject: xtc-devel: xtc future features Hi, Gr8 to have an XTGold clone, it sure was my favorite file manager / hex editor. I have the dutch version of xtgold, version 2.51. I know it's not the last version, but this one works for me. Will there be multilingual support for xtc ? I'll be happy to do the dutch texts :) Also, please support the DOS Attributes when on a (V)Fat filesystem (and maybe on ncpfs and smbfs in the future too), as unix attributes have no real use on files there. Best regards, Dimitri --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Tue, 18 May 1999 22:00:05 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: xtc future features Dimitri Ars wrote: > > Hi, > > Gr8 to have an XTGold clone, it sure was my favorite file manager / hex > editor. > I have the dutch version of xtgold, version 2.51. I know it's not the last > version, but this one works for me. > > Will there be multilingual support for xtc ? I'll be happy to do the dutch > texts :) Eventually there will most likely be, but it's a fair way off yet as I would like to implement all the main features first. > > Also, please support the DOS Attributes when on a (V)Fat filesystem (and > maybe on ncpfs and smbfs in the future too), as unix attributes have no > real use on files there. I'll look into it, although I don't know how possible this would be and if it would affect the portability of the program. But we'll see. > > Best regards, > > Dimitri > > --- > For more info on XTC, visit http://www.area51.org.au/xtc > To unsubscribe from this list, send a message to > majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the > message body. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 4 Jul 1999 20:41:10 +0200 (MEST) From: Mathias Winkler To: XTC developers Subject: xtc-devel: XTC development continuation!?... Hello to all! I wonder what happens to the XTC development, it started furious, however, now there haven't been any news since more than a month now. Let me express how important I think the XTC project for Linux is, since it is undoubtely the best XTree clone for this "real" OS yet, and it may become as powerful under Linux as ZTreeWin under Win9x/NT now is! With all the best wishes for the developing XTC-code!... ;-) Mathias -- mathias winkler - muenchen/munich, germany mailto:mat.winkler@arkanda.net XTree Fan Page -=- http://xtfp.arkanda.net Celibidache Schueler Homepage -=- http://www.arkanda.net/konzerte --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Tue, 06 Jul 1999 14:42:40 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC development continuation!?... Hello Mathias, sorry I haven't had a chance to reply to your message until now. I've been fairly busy lately with full time study + part time work, but I've just completed my end-of-semester exams and am on holidays now. I intend to spend a fair amount of time this week and in the following weeks on the project. Since the last version I released I have been working on a configuration screen, and I haven't got any (real) options implemented yet but all the code is there to do it, so that is not far off completion. Also, to get myself back into the project I have begun writing some documentation. Don't worry, I haven't forgotton about this project and I too would like to see it eventually on par with ZTree, as I imagine others will to. Mathias Winkler wrote: > > Hello to all! > > I wonder what happens to the XTC development, it started furious, however, > now there haven't been any news since more than a month now. > > Let me express how important I think the XTC project for Linux is, since it > is undoubtely the best XTree clone for this "real" OS yet, and it may > become as powerful under Linux as ZTreeWin under Win9x/NT now is! > > With all the best wishes for the developing XTC-code!... ;-) > Mathias > -- > mathias winkler - muenchen/munich, germany > mailto:mat.winkler@arkanda.net > XTree Fan Page -=- http://xtfp.arkanda.net > Celibidache Schueler Homepage -=- http://www.arkanda.net/konzerte > > --- > For more info on XTC, visit http://www.area51.org.au/xtc > To unsubscribe from this list, send a message to > majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the > message body. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Thu, 8 Jul 1999 06:18:46 +0200 (MEST) From: Mathias Winkler To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC development continuation!?... Hello Peter ! > [...] sorry I haven't had a chance to reply to your message > until now. I've been fairly busy lately Don't mind, me too!... ;-) > with full time study + part time > work, but I've just completed my end-of-semester exams and am on > holidays now. I intend to spend a fair amount of time this week and in > the following weeks on the project. Oh, I see! All the best for your project ! > Since the last version I released I have been working on a configuration > screen, and I haven't got any (real) options implemented yet but all the > code is there to do it, so that is not far off completion. Also, to get > myself back into the project I have begun writing some documentation. > That's great ! What about some further ones of the key functions that makes up a significant amount of XTree's power, above all, IMHO, CTRL-'S'earch all tagged files!? > Don't worry, I haven't forgotton about this project and I too would like > to see it eventually on par with ZTree, as I imagine others will to. > Very glad to hear, that's my dream, to have an XTreeGold clone for Linux/Unix as powerful as ZTree for Win32s is (currently I wander around between Midnight Commander :-( , ytree, xtree for UNIX, and, of course, XTC, hope I'll soon can use just the latter for any advanced file managing purpose..). With best regards Mathias -- mathias winkler - muenchen/munich, germany mailto:mat.winkler@arkanda.net XTree Fan Page -=- http://xtfp.arkanda.net Celibidache Schueler Homepage -=- http://www.arkanda.net/konzerte --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 25 Jul 1999 01:41:01 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: xtc-devel: XTC 0.1.8 Hello everyone, Version 0.1.8 of XTC is finally available. The development has been fairly slow over the last couple of months, but now I've added a configuration screen (plus a whole lot of options), multiple columns in the file window and a prune command. I've also started on some documentation (in the file docs.html in the distribution), which documents all the commands and keys that are available. I'd say that the first stage of the program, is about 80% complete. All that needs to be added is a few features, and some minor bugs fixed up. After that's done I'll starting worryng about editors, tar.gz/zip/bzip2/etc. support. The main thing the program needs now is testing..... I don't know of many bugs but I'm sure there's some more in there that are waiting to be found. You can get it from ftp://ftp.area51.org.au/pub/xtc/xtc-0.1.8.tar.gz Enjoy..... -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sat, 24 Jul 1999 20:22:18 +0200 (MEST) From: Mathias Winkler To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC 0.1.8 Hello Peter, hello everyone ! On Sun, 25 Jul 1999, Peter Kelly wrote: > Version 0.1.8 of XTC is finally available. The development has been > fairly slow over the last couple of months, but now I've added a > configuration screen (plus a whole lot of options), Great, congratulations ! The configuration program now looks even more complete than ZTreeWin's after 3 years of development... (Sorry, Kimbo... ;-) However, ZTree as well as XTree, of course, do invoke the configuration screen with ALT-F10, so why in the world does XTC use F2 instead ??? > multiple columns in > the file window and a prune command. I've also started on some > documentation (in the file docs.html in the distribution), which > documents all the commands and keys that are available. Looks very good ! Just another small annotation: Left and right cursor keys in directory window, now added in 0.1.8, have slightely different behaviour in original XTree: Right arrow: Moves down the current path to the last subdirectory in that path Left arrow: Moves to the parent of the current directory, stopping when the parent is the first-level subdirectory (Taken from the XTree Fan Page - "Hidden Hotkeys" section at: http://xtfp.arkanda.net/x43hhl.htm#leftright_arr ) IMHO, XTC should do the same! > After that's done I'll starting worryng about editors, Hm, why "editors" ? - There's Vi on any Unix system, are there other editors, too?... ;-) > tar.gz/zip/bzip2/etc. support. Yeah, that's definitely a good point to work on! > Enjoy..... Sure we'll do!... ;-) Best regards Mathias -- mathias winkler - muenchen/munich, germany mailto:mat.winkler@arkanda.net XTree Fan Page -=- http://xtfp.arkanda.net Celibidache Schueler Homepage -=- http://www.arkanda.net/konzerte --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 25 Jul 1999 14:16:18 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC 0.1.8 Mathias Winkler wrote: > However, ZTree as well as XTree, of course, do invoke the configuration > screen with ALT-F10, so why in the world does XTC use F2 instead ??? Again, another problem with the way keys are handled. I don't think there's any way I can detect ALT-F10 - I don't know if that keycode can be received. I much prefered the handling of keys under DOS - you could just get a keycode, and handle it from there. And you could tell when certain keys like shift, ctrl and alt were held down. You can do it directly under the Linux console, but it won't work from xterm or via a telnet session. This key may change in the future, but I've left it as F2 for now until I can work something better out. It's the same sort of thing as with the moved tagged command - I have had to use CTRL-K because when you press CTRL-M it sends the same keycode as ENTER. > Just another small annotation: > > Left and right cursor keys in directory window, now added in 0.1.8, have > slightely different behaviour in original XTree: > > Right arrow: Moves down the current path to the last subdirectory in that > path > Left arrow: Moves to the parent of the current directory, stopping when > the parent is the first-level subdirectory I know about the left arrow one - I'll have to check the right arrow though. I thought that it made more sense to have it go back to the root, but now I think about it, you can just press HOME to get there anyway, so guess I'll put this back the way it was. > > After that's done I'll starting worryng about editors, > Hm, why "editors" ? - There's Vi on any Unix system, are there other > editors, too?... ;-) Oh please :) Well, vi fans can use that if they want (you can specify which editor you want to use in configuration), but personally I can't stand vi, pico is better but not good enough. The editor in midnight commander seems reasonably close to XTree's editor, so I may base it on that. And of course we need a hex editor too. -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Mon, 26 Jul 1999 05:48:10 +0200 (MEST) From: Mathias Winkler To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC 0.1.8 Hello Peter, hello everyone ! > > However, ZTree as well as XTree, of course, do invoke the configuration > > screen with ALT-F10, so why in the world does XTC use F2 instead ??? > Again, another problem with the way keys are handled. I don't think > there's any way I can detect ALT-F10 - Oh, yes, I see! Anyway, my Linux actually does detect Alt-F10, however, in console mode this takes me to some kind of login status screen (?), similar to Alt-F1 to F6, which toggles between the 6 login consoles. So I'm afraid we can't *any* Alt-Fx key for XTC either.. :-( > I don't know if that keycode can > be received. I much prefered the handling of keys under DOS - you could > just get a keycode, and handle it from there. And you could tell when > certain keys like shift, ctrl and alt were held down. You can do it > directly under the Linux console, but it won't work from xterm or via a > telnet session. > So there really seem to be some disadvantages of Linux compared to DOS!?... > This key may change in the future, but I've left it as F2 for now until > I can work something better out. It's the same sort of thing as with the > moved tagged command - I have had to use CTRL-K because when you press > CTRL-M it sends the same keycode as ENTER. > Oops, I see (again), never thought about that, now I know why Werner Bregulla's "ytree", for example, uses Ctrl-N for Moving all tagged files ! > > Left and right cursor keys in directory window, now added in 0.1.8, have > > slightely different behaviour in original XTree: > > Right arrow: Moves down the current path to the last subdirectory in that > > path > > Left arrow: Moves to the parent of the current directory, stopping when > > the parent is the first-level subdirectory > > I know about the left arrow one - I'll have to check the right arrow > though. I thought that it made more sense to have it go back to the > root, but now I think about it, you can just press HOME to get there > anyway, so guess I'll put this back the way it was. > Yeah, great, glad to hear ! (In particular for reasons of XTree compatibility) > Well, vi fans can use that if they want (you can specify which editor > you want to use in configuration), but personally I can't stand vi, pico > is better but not good enough. The editor in midnight commander seems > reasonably close to XTree's editor, so I may base it on that. > The mc default editor has some sort of Emacs-like key-bindings, while XTree's editor 1Word uses the (80s quasi standard) WordStar keytrokes, however, this really seems to be a matter of taste, or what you are used to. Anyway, a great and widespread Unix editor with WordStar bindings is "Joe" (run as "jstar") and, moreover, Joe can emulate EMacs bindings, too, it even offers a much enhanced Pico "version" (jpico). Sources at: ftp://ftp.std.com/customers3/src/editors/joe2.8.tar.Z Best regards Mathias -- mathias winkler - muenchen/munich, germany mailto:mat.winkler@arkanda.net XTree Fan Page -=- http://xtfp.arkanda.net Celibidache Schueler Homepage -=- http://www.arkanda.net/konzerte --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. From: Robert Klein Date: Tue, 27 Jul 1999 08:56:01 +0200 (MET DST) To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC 0.1.8 Mathias Winkler writes: > Oh, yes, I see! Anyway, my Linux actually does detect Alt-F10, however, in > console mode this takes me to some kind of login status screen (?) which makes you using SuSE Linux ;-) > > Well, vi fans can use that if they want (you can specify which editor > > you want to use in configuration), but personally I can't stand vi, pico > > is better but not good enough. The editor in midnight commander seems > > reasonably close to XTree's editor, so I may base it on that. > The mc default editor has some sort of Emacs-like key-bindings, while > XTree's editor 1Word uses the (80s quasi standard) WordStar keytrokes, > however, this really seems to be a matter of taste, or what you are used > to. Anyway, a great and widespread Unix editor with WordStar bindings is > "Joe" (run as "jstar") and, moreover, Joe can emulate EMacs bindings, too, > it even offers a much enhanced Pico "version" (jpico). Sources at: > ftp://ftp.std.com/customers3/src/editors/joe2.8.tar.Z I would not base the editor on the original XTG, because most Unix folks are long converted to something other and don't remember WS key codes that well. I'd personally prefer pico as default (for now) as it shows its most important command keys in the bottom two lines. Perhaps you let the configuration program look for /bin/vi, /usr/bin/pico, /usr/bin/memacs and offer these as 3, 1 and 2 respectively with the option to enter a custom editor. regards, Robert (now looking how 0.1.8 does on an Ultra2 with AFS) --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 01 Aug 1999 19:46:07 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: Re: xtc-devel: XTC 0.1.8 Robert Klein wrote: > I would not base the editor on the original XTG, because most Unix > folks are long converted to something other and don't remember > WS key codes that well. I'd personally prefer pico as default > (for now) as it shows its most important command keys in the > bottom two lines. Perhaps you let the configuration program > look for /bin/vi, /usr/bin/pico, /usr/bin/memacs and offer these > as 3, 1 and 2 respectively with the option to enter a custom > editor. I don't think basing it on the original editor is too much of a problem - the main goal of this clone is so that XTree users will feel more at home under UNIX, and having an editor that works in the same way is part of the overall experience. Personally, I don't think that the WS-style type of editor is the "best" (perhaps "my favourite" would be a better term to use), but I believe that in this case it is better to be consistent with the original rather than making too many changes that make the program feel different. I certainly haven't been converted to vi/emacs yet after two years of running Linux - in fact I prefer the editing style used by all windows applications and now many others such as Nedit and KDE apps. But everyone has their pet editor which they would like to use and they should be able to do that, which is why it is customizable. I prefer the current method of specifying the editor, because it's easy to type in the name, and some people might have these binaries located elsewhere, like /usr/local/bin or /opt/emacs/bin etc. (and also because it works in the same way as XTree's configuration program). -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body. Date: Sun, 15 Aug 1999 01:11:16 +0930 From: Peter Kelly To: xtc-devel@area51.org.au Subject: xtc-devel: XTC 0.1.9 Version 0.1.9. Nothing has changed feature-wise, however I discovered a few fairly important bugs which have now been fixed: - "Floating Exception" crash when entering a directory with filenames longer than the width of the file window (bug only present in 0.1.8?) - Owner/group of files and directories was not updated after changed, until the files or directories were re-logged (bug only present in 0.1.8) - no. of columns not always set properly when in branch mode - when in full-sized file window, and filespec set to something that no files in the file window match, and program switches back to directory window, directory window not redrawn - wrong owners & groups for files & directories being displayed - crash when using the attributes command in the file window You can get it at: ftp://ftp.area51.org.au/pub/xtc/xtc-0.1.9.tar.gz -- Peter Kelly peter@area51.org.au --- For more info on XTC, visit http://www.area51.org.au/xtc To unsubscribe from this list, send a message to majordomo@area51.org.au with the command "unsubscribe xtc-devel" in the message body.