Re: [ql-users] Qeymail, last call for suggestions...
On Mon, 11 Nov 2002, James Hunkins wrote: Yes, ProWess is much, much, MUCH easier to program and more powerful. You could even, one day, add HTML email rendering... That isn't a 'one day' thing. I plan to incorporate understanding of HTML from day 1, and have configuration that allows people to select what HTML elements get displayed. There will also be a header handler, so if you email a file/program to another QLer, the file can be saved on their system with header. I really don't understand why people don't program using the ProWess window manager. The usual complain was that it needed a fast QL. But Since this is email for those with ethernet, and ethernet would be highly unsatisfactory on a 20MHz machine, I don't think it s TOO important to serve that group. I do plan that keypresses will work, and the key labels on screen (bottom two lines, just like pine) will also be clickable. And there are a lot of people around who can help. I believe that the intent was to do the development work in S-Basic. Easy pointer should work well there. Adding GD2 (full color) takes a bit of experimenting but can be done after all the major window/menu work is complete. I am doing the QDT color tuning towards the end of all the actual code myself. In a way I am lucky. You have all been playing with these goodies for years, and here I am, back after a 12 year absense, and there's all this new stuff! Ok, back to work. Dave
Re: [ql-users] Qeymail, last call for suggestions...
On Mon, 11 Nov 2002, James Hunkins wrote: I don't like the idea of a single file. Take a look at Microsoft's email program - there have been many problems with the single file once it gets too large. Things slow down, corruption is possible, and trying to extract and save individual emails gets 'interesting'. I don't like the idea of a single file either, because removing an email from the middle of a file and closing up thew gap is slow if done on a drive, or would exhaust memory. I don't want to divide email by date either. Finally, I do not want to divide email by sender email, because the penalty is that the ones who send most mail have the largest files and slowest response. Instead, I am aiming towards a subdirectory structure, thus: inbox_index inbox_1211020001 . . inbox_121102 (ie can handle 65536 mails a day) delet_index delet_1211020001 etc... I will also allow people to create their own folders and move mail between folders. Someone else mentioned the QL file limitations per directory. This could become a problem for someone who gets a lot of emails. You might I think if people really store that much mail, I will have it auto archive mail, and inform the user. EG: on start up it can say You have over 30,000 emails. Call Geeks Anonymous on... *grins* Also, are you aiming this at all users including floppy and microdrive types? If so, what happens if a user fills up a floppy, etc (for some of us, this is a real possibility). I will allow each folder to be on a different drive, so inbox could be on flp1_ and others on flp#_ - all user-assignable. I think it will be important to include mail backup facilities, just to be on the safe side for everyone. Dave
RE: [ql-users] Qeymail, last call for suggestions...
On Tue, 12 Nov 2002, Norman Dunbar wrote: Hi Dave, Hi Norman, if you are going to use PE and you want to do it 'easily' get hold of EasyPtr (somehow) and there is a totally excellent tutorial avaiulable for download somewhere (Dilwyn's web emporium I think) which shows how to use it without having to go through the same steep learning curve that the author had to. I'll look out for it. I'll keep my eyes open for easy manuals. I tend to not retain things as well as when I was younger, so these days I seem to spend half my time writing wrappers so I can address difficult-to-do things in easy ways. I look forward to writing lots of tasty S*BASIC wrappers for SOQL. :o) Until I wrote that tutorial (oops !) I used to call the system DifficultPointer - ask Dilwyn, I had many a rant in those days :o) Yup. All these counter-intuitive commands and unpredictable/conditional results based on factors you have no use over. One thing I am considering is putting up some of the useful procedures, like the SOQL wrappers, unix-QL date format converters, etc up on my site so people can use them in their projects. Life is too short not to have fun! :o) Dave
Re: [ql-users] Qeymail, last call for suggestions...
On 11 Nov 2002, at 13:33, Dave P wrote: > Finally, how important would it be to use a pointer environment, or would > you be happy to use industry standard CTRL-key combinations? For, it would be PE, Prowess or nothing... If you want, I could probably rapidly build you a prototype PE application, all in Sbasic, to which you could add later. Prowess would take a bit more time... Wolfgang
Re: [ql-users] Qeymail, last call for suggestions...
On Tue, 12 Nov 2002, Wolfgang Lenerz wrote: For, it would be PE, Prowess or nothing... It'll be open source, and I can do it with pointers, and anyone who wants it without pointers can take the source and edit it ;) If you want, I could probably rapidly build you a prototype PE application, all in Sbasic, to which you could add later. Prowess would take a bit more time... I appreciate the offer, but I really should learn how to do it myself. :o) Dave
Re: [ql-users] Qeymail, last call for suggestions...
Sounds very clean. I am looking forward to your program. It should also fit very cleanly into the QDT environment, especially since you plan to use the pointer environment. QDT will also be able to take advantage of the standard config blocks and will eventually offer a 'free' to use installer based on scripts which you might like to adapt to your distribution (does not require QDT to run). This will be available sometime next year. Have fun, Jim On Tuesday, November 12, 2002, at 06:57 AM, Dave P wrote: On Mon, 11 Nov 2002, James Hunkins wrote: I don't like the idea of a single file. Take a look at Microsoft's email program - there have been many problems with the single file once it gets too large. Things slow down, corruption is possible, and trying to extract and save individual emails gets 'interesting'. I don't like the idea of a single file either, because removing an email from the middle of a file and closing up thew gap is slow if done on a drive, or would exhaust memory. I don't want to divide email by date either. Finally, I do not want to divide email by sender email, because the penalty is that the ones who send most mail have the largest files and slowest response. Instead, I am aiming towards a subdirectory structure, thus: inbox_index inbox_1211020001 . . inbox_121102 (ie can handle 65536 mails a day) delet_index delet_1211020001 etc... I will also allow people to create their own folders and move mail between folders. Someone else mentioned the QL file limitations per directory. This could become a problem for someone who gets a lot of emails. You might I think if people really store that much mail, I will have it auto archive mail, and inform the user. EG: on start up it can say You have over 30,000 emails. Call Geeks Anonymous on... *grins* Also, are you aiming this at all users including floppy and microdrive types? If so, what happens if a user fills up a floppy, etc (for some of us, this is a real possibility). I will allow each folder to be on a different drive, so inbox could be on flp1_ and others on flp#_ - all user-assignable. I think it will be important to include mail backup facilities, just to be on the safe side for everyone. Dave
Re: [ql-users] Qeymail, last call for suggestions...
[Qeymail] Darn, I can't keep up with you all even with a broadband connection - and to think that a few weeks ago people were complaining the list was dead... IIRC there is a serious limitiation in SOME file systems, and this is a _TOTAL_ number of files on a drive, which, IIRC is 65535 (if coded correctly) and 32767 if the author forgot to use unsigned 16-bit integers. The problem is endemic to all purely FAT based systems because the structure is based on a table where each entry means physical sector (index in table) is sector X of file Y - where both X and Y are of some predetermined size - 12 bits on floppy, 16 on hard drive. The same structure is inherited into directories, because you want to alow one directory to use the whole available number of files, if needed. But, there is always a limit. I am not sure what it is for TTs HDD (and QXL.win) driver, though. For a file organisation, I would vote for inbox = directory, email = file. Basically, keep the inbox organisation in the index file - this includes any sub-folders in it, deleted files, compressed files, etc, etc. Directory and file names should obviously be kept short (36 characters to a path + name limit...), so I suppose the file names should be somehow 'hashed' or encoded from a date or just have an ever increasing number. One could encode a 32-bit number plus a few extra flag bits into 6 bit + offset ASCII. This would give us 10 character names. The index file would hold the actual structure (which email file goes where). The user could then have an option to periodically physically delete all files marked as deleted. Also, the number of files should be kept to a sane number, once this is reached, the user could be prompted to compress older files - these could simply be zipped into one larger file. This would then also have an encoded name, which would, for example, reference the newest message in the archive (for search purposes). Finally: a small 'I told you so' for the people who keep saying the file system is just fine and that 36 characters are enough. Funny how this can turn out to be a limitation even for a 'simple' application, isn't it? I TOLD YOU SO! Nasta
Re: [ql-users] Qeymail, last call for suggestions...
I got hung up on the bitfield and forgot the rest. Let's try again. On Tue, 12 Nov 2002, Dave P wrote: I'm currently working on how much to put in the index - quite a lot, because it'll save a lot of time. 121102001:[EMAIL PROTECTED]::[timeasinteger]:[timezone]:Subject text The bitfield will actually be an integer, but I expressed it in this example as bits: 0 Received (1=sent with this client 0=sent with any other client) 1 Read 2 Reply sent 3 Forwarded 4 - reserved 5 - reserved 6 Archived 7 Deleted [timeasinteger] will be the sent timestamp. timezone will allow the correct time to be displayed in the client. Subject is, well :o) If there's anything else that you think would be useful to have in the index, please say so now, though it will be quite easy to change later. Dave
Re: [ql-users] Qeymail, last call for suggestions...
On 12/11/02 at 14:03 Dave P wrote: The bitfield will actually be an integer, but I expressed it in this example as bits: 0 Received (1=sent with this client 0=sent with any other client) 1 Read 2 Reply sent 3 Forwarded 4 - reserved 5 - reserved 6 Archived 7 Deleted [timeasinteger] will be the sent timestamp. timezone will allow the correct time to be displayed in the client. Subject is, well :o) If there's anything else that you think would be useful to have in the index, please say so now, though it will be quite easy to change later. 'Has attachment' 'Attachment removed' Every once in a while sort by attachment is VERY useful (as in: someone sent me a file, where is it?). Attachment removed is also interesting in case you want to only archive the actual messages without attachments or just remove attachments after a while to save space. N.
Re: [ql-users] Qeymail, last call for suggestions...
On Tue, 12 Nov 2002, ZN wrote: 'Has attachment' 'Attachment removed' Every once in a while sort by attachment is VERY useful (as in: someone sent me a file, where is it?). Attachment removed is also interesting in case you want to only archive the actual messages without attachments or just remove attachments after a while to save space. Both good suggestions, added to the spec. I will extend the bitfield to 16 bits, or two 8-bit fields, one for status and one for content. Or something. :o) Thanks Nasta. Nice to see you becoming a useful member of society again ;P Dave
Re: [ql-users] Qeymail, last call for suggestions...
if you are going to use PE and you want to do it 'easily' get hold of EasyPtr (somehow) and there is a totally excellent tutorial avaiulable for download somewhere (Dilwyn's web emporium I think) Indeed, or can be emailed direct if you wish. Until I wrote that tutorial (oops !) I used to call the system DifficultPointer - ask Dilwyn, I had many a rant in those days :o) I remember the DifficultPointer era well. It was largely my inability to master it at first which caused the long gap between Albin Hessler sending me a sample copy and me actually starting to sell it via DJC. It's not really difficult. Just a lot to master in one go. And a lot of terminology to get used to. Norman's tutorial is a real step by step basics guide. -- Dilwyn Jones
Re: [ql-users] Qeymail, last call for suggestions...
Finally: a small 'I told you so' for the people who keep saying the file system is just fine and that 36 characters are enough. Funny how this can turn out to be a limitation even for a 'simple' application, isn't it? I TOLD YOU SO! Nasta Huh, just try using the DOS device in QPC (dos1_ = c:\) to access folders of any depth in the other OS's hard disk and you'll quickly find 36 to be a limit. I have a habit of dumping downloaded files onto the desktop (not good practice I know but still...) and then accessing dos1_windows_desktop_ and there's 16 of your 36 characters gone already. Thank you Marcel for allowing the dos devices to be redefined to work around this! -- Dilwyn Jones
Re: [ql-users] Qeymail, last call for suggestions...
In article [EMAIL PROTECTED], Dave P [EMAIL PROTECTED] writes On Mon, 11 Nov 2002, Malcolm Cadman wrote: A good index is essential. I plan to give every email a serial number. Whether a single file or one file per email, there will be an index file with serial number, filename, length, date, status, etc. I am even considering copying exactly the pine mailbox format, so mail would be portable to-from linux systems. That could be eminently sensible ... as the Q40 / Q60 has ability to run Linux. I use multiple mailboxes all the time ... so I guess I am just used to it. I have thought of a nice, easy way to resolve that issue. I figured as much :-) Must have the PE for me. *pout* :o) -- Malcolm Cadman
Re: [ql-users] Qeymail, last call for suggestions...
In message 011601c28a98$c6658800$70065cc3@blackpc, Dilwyn Jones [EMAIL PROTECTED] writes SNIP Huh, just try using the DOS device in QPC (dos1_ = c:\) to access folders of any depth in the other OS's hard disk and you'll quickly find 36 to be a limit. I have a habit of dumping downloaded files onto the desktop (not good practice I know but still...) And the more you have on the desktop the more it slows the machine down because it constantly has to refresh all those files. -- Roy Wood Q Branch, 20 Locks Hill Portslade. Sussex. BN41 2LB. UK Tel : +44 (0)1273 386030 Fax : +44 (0)1273 430501 (New number!) Mobile +44(0)7836 745501 Web : www.qbranch.demon.co.uk
Re: [ql-users] Qeymail, last call for suggestions...
On 12/11/02 at 15:57 Dave P wrote: Thanks Nasta. Nice to see you becoming a useful member of society again ;P Why, thank you! I think... N.
[ql-users] Qeymail, last call for suggestions...
Hi all, While I've done a lot of work on look-and-feel stuff for Qeymail, there are some behind the scenes things I'm not too sure about. Where three or four strategies exist to solve a problem, different solutions will benefit different types of user, and I want to create the best experience for the largest number of people possible. The main area is the actual storage method for emails. Would people prefer a single file holding all emails, individual files for each email, which would be indexed on startup, or individual files plus a maintained index? Each has plusses and minuses. Discuss. Second, multiple mail boxes. Is the ability to send/receive from multiple mailboxes useful or not? What about profiles where one profile is accessed at a time, or is the ability to access multiple mailboxes simultaneously 'very important' to you? Finally, how important would it be to use a pointer environment, or would you be happy to use industry standard CTRL-key combinations? Thanks in advance, Dave
Re: [ql-users] Qeymail, last call for suggestions...
While I've done a lot of work on look-and-feel stuff for Qeymail, there are some behind the scenes things I'm not too sure about. Where three or four strategies exist to solve a problem, different solutions will benefit different types of user, and I want to create the best experience for the largest number of people possible. The main area is the actual storage method for emails. Would people prefer a single file holding all emails, individual files for each email, which would be indexed on startup, or individual files plus a maintained index? Each has plusses and minuses. Discuss. No real strong views either way, both have their merits. Second, multiple mail boxes. Is the ability to send/receive from multiple mailboxes useful or not? What about profiles where one profile is accessed at a time, or is the ability to access multiple mailboxes simultaneously 'very important' to you? Finally, how important would it be to use a pointer environment, or would you be happy to use industry standard CTRL-key combinations? Thanks in advance, Dave With two pointer driven 'desktop' programs (one QDT for GD2/SMSQE systems the other Launchpad for more basic QDOS and SMSQE systems) and a fair bit of interest shown in those too (well, in mine anyway, won't speak for Jim Hunkins as he presumably gets private mail about his system like I do mine), I'd suggest going for pointer environment if feasible. Is Qeymail based on soql or have you got your own web access routines? -- Dilwyn Jones
Re: [ql-users] Qeymail, last call for suggestions...
The main area is the actual storage method for emails. Would people prefer a single file holding all emails, individual files for each email, which would be indexed on startup, or individual files plus a maintained index? Why not use one the of databases which are available (DATAdesign (as in part of ProWesS) springs to mind). Joachim
Re: [ql-users] Qeymail, last call for suggestions...
Pointer Environment is EVER better ! - Original Message - From: Phoebus Dokos [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 11, 2002 9:25 PM Subject: Re: [ql-users] Qeymail, last call for suggestions... ??? 11/11/2002 2:33:34 ??, ?/? Dave P [EMAIL PROTECTED] ??: Hi all, While I've done a lot of work on look-and-feel stuff for Qeymail, there are some behind the scenes things I'm not too sure about. Where three or four strategies exist to solve a problem, different solutions will benefit different types of user, and I want to create the best experience for the largest number of people possible. The main area is the actual storage method for emails. Would people prefer a single file holding all emails, individual files for each email, which would be indexed on startup, or individual files plus a maintained index? One single file would simplify storage, preferably stored as a markup language text file of sorts (so it can accomodate different codepages etc..). After that you can have an export function (like Netscape or Eudora for example) to extract the specific message if the user wants. Each has plusses and minuses. Discuss. Second, multiple mail boxes. Is the ability to send/receive from multiple mailboxes useful or not? What about profiles where one profile is accessed at a time, or is the ability to access multiple mailboxes simultaneously 'very important' to you? Well that wouldn't complicate things too much would it? I mean think about it.. combined with a single storage mailbox file (well actually one for each folder per se, you only need to add an entry on which user this pertains to. Finally, how important would it be to use a pointer environment, or would you be happy to use industry standard CTRL-key combinations? Although at first it seems simpler to make a standard non-PE program, using tools like Q-Menu and EASYPTR would simplify your developing process significantly... Phoebus P.S. I have the answer to your question (the one you asked yesterday before we got on AIM... ICQ me for details...)
Re: [ql-users] Qeymail, last call for suggestions...
On Mon, 11 Nov 2002, Joachim Van der Auwera wrote: Why not use one the of databases which are available (DATAdesign (as in part of ProWesS) springs to mind). This will be a free, open source program. If it relies on any other program, that program would also have to be free, and I would need to be able to distribute it, or offer it for download, as part of the package. I'll also be doing this co-operateively with anyone who wants to help... Dave
Re: [ql-users] Qeymail, last call for suggestions...
Why not use one the of databases which are available (DATAdesign (as in part of ProWesS) springs to mind). This will be a free, open source program. If it relies on any other program, that program would also have to be free, and I would need to be able to distribute it, or offer it for download, as part of the package. I'll also be doing this co-operateively with anyone who wants to help... ProWesS is free including all libraries which are part of it (like the DATAdesign engine). There is a GUI for the DATAdeisng engine (also called DATAdesign) which is not free though. Joachim
Re: [ql-users] Qeymail, last call for suggestions...
??? 11/11/2002 4:25:07 ??, ?/? Dave P [EMAIL PROTECTED] ??: On Mon, 11 Nov 2002, Dilwyn Jones wrote: I'd suggest going for pointer environment if feasible. Another thing to learn ;) I'll spend the first few weeks just building the structure and getting back-room stuff working, like DNS and connecting to a mail server. Is Qeymail based on soql or have you got your own web access routines? It will be based on soql, as I'm not competent to write a TCP stack ;) There also the new stack from Peter Graf as well (see announcement in QL- developers last month) As long as it's based on the C68 BSD libraries I don't see why it wouldn't work there too :-) Phoebus
Re: [ql-users] Qeymail, last call for suggestions...
??? 11/11/2002 4:40:03 ??, ?/? Joachim Van der Auwera [EMAIL PROTECTED] ??: Why not use one the of databases which are available (DATAdesign (as in part of ProWesS) springs to mind). This will be a free, open source program. If it relies on any other program, that program would also have to be free, and I would need to be able to distribute it, or offer it for download, as part of the package. I'll also be doing this co-operateively with anyone who wants to help... ProWesS is free including all libraries which are part of it (like the DATAdesign engine). There is a GUI for the DATAdeisng engine (also called DATAdesign) which is not free though. Joachim In that case DATAdesign for the use you want is the best Dave! Phoebus
Re: [ql-users] Qeymail, last call for suggestions...
In article [EMAIL PROTECTED], Dave P [EMAIL PROTECTED] writes While I've done a lot of work on look-and-feel stuff for Qeymail, there are some behind the scenes things I'm not too sure about. Where three or four strategies exist to solve a problem, different solutions will benefit different types of user, and I want to create the best experience for the largest number of people possible. The main area is the actual storage method for emails. Would people prefer a single file holding all emails, individual files for each email, which would be indexed on startup, or individual files plus a maintained index? Each has plusses and minuses. Discuss. I don't know in detail what the issues are. A single file seems more likely to get corrupted / go wrong - so may lose mails. A good index is essential. Second, multiple mail boxes. Is the ability to send/receive from multiple mailboxes useful or not? What about profiles where one profile is accessed at a time, or is the ability to access multiple mailboxes simultaneously 'very important' to you? I use multiple mailboxes all the time ... so I gues I am just used to it. Finally, how important would it be to use a pointer environment, or would you be happy to use industry standard CTRL-key combinations? Must have the PE for me. -- Malcolm Cadman
Re: [ql-users] Qeymail, last call for suggestions...
On Mon, 11 Nov 2002, Phoebus Dokos wrote: In that case DATAdesign for the use you want is the best Dave! I plan to do developmental work in S*BASIC. I like to clearly lay out in very readable fashion how everything works, especially the transactions between servers. It'll be a simple test rig. Once the mechanics are shown to work, I may (will?) start over using PE. People are advising I use a database program, but that's the least of my worries - I'm more worried about the email editor! ;) Finally, I plan to make some of the sections portable, so later they can be used in a simple S*BASIC web server, mail SERVER, or similar. As I said previously, all this will be open source, probably under the LGPL. Basically, if you sell or give the code to someone, you have to give them the source if they ask for it. Anything else? There isn't a cut-off for suggestions, but I'd like as much in before I do fundamentals, and before it's difficult to do major restructuring. Also, a quickie, is there a QL equivalent of MD5 hashing so I can securely store passwords? Dave
Re: [ql-users] Qeymail, last call for suggestions...
On Mon, 11 Nov 2002, Malcolm Cadman wrote: A good index is essential. I plan to give every email a serial number. Whether a single file or one file per email, there will be an index file with serial number, filename, length, date, status, etc. I am even considering copying exactly the pine mailbox format, so mail would be portable to-from linux systems. I use multiple mailboxes all the time ... so I guess I am just used to it. I have thought of a nice, easy way to resolve that issue. Must have the PE for me. *pout* :o) Dave
Re: [ql-users] Qeymail, last call for suggestions...
Ah, now I thought I was subscribed to ql-developers, but it's a long time since I last had an email from it. Would you mind sending me a copy of the email if you still have it? -- Dilwyn Jones - Original Message - From: Phoebus Dokos [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 11, 2002 10:00 PM Subject: Re: [ql-users] Qeymail, last call for suggestions... ??? 11/11/2002 4:25:07 ??, ?/? Dave P [EMAIL PROTECTED] ??: On Mon, 11 Nov 2002, Dilwyn Jones wrote: I'd suggest going for pointer environment if feasible. Another thing to learn ;) I'll spend the first few weeks just building the structure and getting back-room stuff working, like DNS and connecting to a mail server. Is Qeymail based on soql or have you got your own web access routines? It will be based on soql, as I'm not competent to write a TCP stack ;) There also the new stack from Peter Graf as well (see announcement in QL- developers last month) As long as it's based on the C68 BSD libraries I don't see why it wouldn't work there too :-) Phoebus
Re: [ql-users] Qeymail, last call for suggestions...
Dave P writes: The main area is the actual storage method for emails. Would people prefer a single file holding all emails, individual files for each email, which would be indexed on startup, or individual files plus a maintained index? Each has plusses and minuses. Discuss. Imho, the simplest solution would be your last option. However, due to the limitations of the Qdos/SMSQ FS there is a limit on the number of files that can usefully be stored in a directory without slowing down the whole system. (The actual physical limit is 32k files per directory, I believe). With the current name length limit youd probably be better off with sub-directory and filenames reduced to same-length consecutive numbers, with the real names held in an index, or indexes. You might be able to work with zip though, using its directory, name, compression and encryption facilities? (However, file integrity would be difficult to maintain - eg a powercut during file operations could be catastrophic.) Doing it all in one big file would more or less involve writing your own file system! (Could be fun). Second, multiple mail boxes. Is the ability to send/receive from multiple mailboxes useful or not? What about profiles where one profile is accessed at a time, or is the ability to access multiple mailboxes simultaneously 'very important' to you? I dont use such features at present, but it might prove useful. Why not wait until V2.00? Finally, how important would it be to use a pointer environment, or would you be happy to use industry standard CTRL-key combinations? PE is a must for the likes of me. But that would lock some other people out, of course. Perhaps youd have to do two versions ;) Per
Re: [ql-users] Qeymail, last call for suggestions...
Le Lundi, 11 nove 2002, à 20:17 US/Eastern, P Witte a écrit : I plan to do developmental work in S*BASIC. I like to clearly lay out in very readable fashion how everything works, especially the transactions between servers. It'll be a simple test rig. Once the mechanics are shown to work, I may (will?) start over using PE. Or Prowess. Yes, ProWess is much, much, MUCH easier to program and more powerful. You could even, one day, add HTML email rendering... I really don't understand why people don't program using the ProWess window manager. The usual complain was that it needed a fast QL. But these days, with the Q40, Q60 and emulators on fast PCs this is not a problem anymore. I find it runs at an acceptable speed even on my SCG !! It can already use the full range of colors with the GD2 and it is free and open source so it could be made even faster. I, for one, will never again write anything using the PE. Its ugly and difficult to do. I wonder how many developer on this list had tried ProWess/ProForma. Just my 0.02$ but I welcome comments. -- François Lanciault [EMAIL PROTECTED]
Re: [ql-users] Qeymail, last call for suggestions...
Yes, ProWess is much, much, MUCH easier to program and more powerful. You could even, one day, add HTML email rendering... I really don't understand why people don't program using the ProWess window manager. The usual complain was that it needed a fast QL. But these days, with the Q40, Q60 and emulators on fast PCs this is not a problem anymore. I find it runs at an acceptable speed even on my SCG !! It can already use the full range of colors with the GD2 and it is free and open source so it could be made even faster. -- François Lanciault [EMAIL PROTECTED] I would agree that ProWess is much easier to develop in and that the newer systems can handle its requirements without an issue. Unfortunately, many people do not have faster systems so it would lock them out. I had considered using it for QDT but I heard from quite a few people who are fairly active with their QLs but did not have a fast enough system to use it seamlessly. Pointer environment is not as easy but it isn't that bad, especially if you just use a simple basic window with the standard items. In this case I would imagine that the only 'application' window item would be a text display type which should be easy. Once you get through the basics, using the correct tools which someone else mentioned, it is fairly straight forward to program in. And there are a lot of people around who can help. I believe that the intent was to do the development work in S-Basic. Easy pointer should work well there. Adding GD2 (full color) takes a bit of experimenting but can be done after all the major window/menu work is complete. I am doing the QDT color tuning towards the end of all the actual code myself. Jim Hunkins
Re: [ql-users] Qeymail, last call for suggestions...
The main area is the actual storage method for emails. Would people prefer a single file holding all emails, individual files for each email, which would be indexed on startup, or individual files plus a maintained index? I don't like the idea of a single file. Take a look at Microsoft's email program - there have been many problems with the single file once it gets too large. Things slow down, corruption is possible, and trying to extract and save individual emails gets 'interesting'. Someone else mentioned the QL file limitations per directory. This could become a problem for someone who gets a lot of emails. You might want to break it into weekly directories with individual emails or something like that. If too many emails happened (what is the file limit?) then your software could create additional directories for that particular week. Of course, an index is the only way to handle the speed. Also, are you aiming this at all users including floppy and microdrive types? If so, what happens if a user fills up a floppy, etc (for some of us, this is a real possibility). Just some thoughts... Jim Hunkins
