Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: "P Witte" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 04, 2005 6:28 PM Subject: Re: [ql-users] EasyPtr was movig sbasic Snip > > Although, in the fullness of time, the tools that George has > produced to go with TurboPtr, may become replacements for > EasyMen, they are by no means there just yet - at least not > last I looked. However, that is another possibility for the > future. > I think you can do most things with setw & TurboTptr or Cptr that a programmer would want. So what do you think is missing? What do you think should be done to improve the suite? Snip > > Per > > ___ > QL-Users Mailing List > http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: "Wolfgang Uhlig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 04, 2005 8:33 PM Subject: Re: [ql-users] EasyPtr was movig sbasic > P Witte <[EMAIL PROTECTED]> wrote: > > We can live without a good menu designer or a sprite editor, > > but not without a way of displaying and manipulating our > > windows and menus from within programs, so for me that is > > the main priority. > > As to me, I can live without a sprite editor because it's possible to > create sprites > in other ways. > A menu designer à la Easymenu_exe is (and has always been) indispensable > for me when > writing my programs for the QL. This is why my disappointment is so great > at the moment. > You can design menus in setw in TurboPTR. George has also written a program to convert EasyPtr windows to TurboPTR You can them use them for C in Cptr as well. George is also considering adapting setw so it produces. data files for assembler. A little interest from the group will encourage him! > When I started to write programs for/on the QL many years ago, it was > because EP made it > so easy. I was already a "mouse-user" when most QL-users still thought of > a computer-mouse > as the beginning of the end of the world and only Roy dared to have > BUTTONS on his desktop ;) > EP has been my companion and my motivation on the QL. Without it probably > none of my programs > would have seen the world and I would have left the QL-scene long ago. > George also has tools in his suite to create buttons from pictures and setw automatically produces text buttons for programs. Setw enables you to produce menu buttons as well. > During the last two or three years I have always hoped that anyone > (especially Marcel) > would update EP. In only _one_ of his "long nights" Marcel succeeded in > bringing Easymenu to a state > where it can work with colours and 3-D borders! > Marcel says, it is not perfect yet. > I say, it's so much better now and I would even pay for _this_ one, if he > asked me to. > I am convinced that there would be hardly any EP-owner and -user who would > NOT pay for such a > version. The ones I know, wouldn't. > It is so frustrating and annoying that it cannot be given or sold to other > users! > > I am frustrated because of all things, we urgently need to make the QL > survive, software (good, interesting, > funny, useful and whatever programs) is the most important. A colourful > game and a new desktop are not > more than a drop in the bucket. > > Please you people out there, who really have the knowledge to write > utilities > which enable us "lower gods" to write software, > which make it really easy to create it, > which just motivate us to make a start, > please just do it! > > Wolfgang > > > ___ > QL-Users Mailing List > http://www.q-v-d.demon.co.uk/smsqe.htm ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
P Witte schreef: Its a pity Albin is no longer interested in developing EP, but thats life. It needent be such a big task, though. IMHO EP could be split into three or four different projects: 1) EasyMen, 2) EasySprite, 3) the toolkit, 4) C-stuff. 1) EasyMenu: In fact I would be happy with the enhancements already available to some of you: a) the possibility to design the windows in high/palette/system colours. b) the possibility to resize those windows in Sbasic (your MSPRV_obj proves it is possible). 2) EasySprite: An upgrade is not really necessary as there are alternatives at our disposal: Jerôme's Sprite Editor,BMPSPRT_obj (Wolfgang Lenerz),Snatch (?) could be adapted to save in 'sprite format' instead of 'pic format' and for QPC2 users there is PNGConv (Marcel Kilgus). 3) the Toolkit: Some functions/procedures need improvement. For example 'RPXL%' (returns the pixel colour at a given position) only works in QL colours. Including the toolkit in SMSQE is not an option for me: its functions/procedures would be available from the start, that would probably make some existing programmes unuseable because of keyword clashes.( see the messages about 'RESET') C) C-stuff: No comments here as I'm limited to Sbasic. About TurboPtr: the demo George showed us in Eindhoven(QL2004) didn't convince me to abandon EasyMenu. We can live without a good menu designer or a sprite editor, I can't else I wouldn't wait for an upgrade. but not without a way of displaying and manipulating our windows and menus from within programs, so for me that is the main priority. Per Wolfgang Uhlig asked us to fix a price... Well, I'm willing to pay about 50 Euros for an upgrade. François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Am Sat, 5 Mar 2005 10:41:31 - hat jms1 <[EMAIL PROTECTED]> geschrieben: You can design menus in setw in TurboPTR With due respect for the work of Goerge. But I am not willing to design a pointer driven program with a technique of 20 years ago. For me this is absurd. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] ATTN: Roy Wood re my Subscription
Roy wood wrote: In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes Roy, did you get my request to renew QL Toady 'in the usual fashion' - I sent it to sales*qbranch. Cheers, Norman. I did and a receipt is on it's way Thanks - receipt has been received. :o) Cheers, Norman. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
wolfgang mühlegger wrote: > but why did he do it then? Just for fun. > and why did he give it to beta-testers then? There were no "beta testers". I just gave it to some people and said "look, mom, without hands". Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
- Original Message - From: "wolfgang mühlegger" To: <[EMAIL PROTECTED]> Sent: Friday, March 04, 2005 9:06 PM Subject: Re: [ql-users] EasyPtr was movig sbasic gwicks schrieb: Nevertheless Marcel has already made a considerable improvement to EasyPtr, but as yet it is only available to a few "beta testers". A pity for this work to be wasted by not being available (for a payment) to a wider group of users. but why did he do it then? and why did he give it to beta-testers then? As I understand it the history is as follows: When QL-ers first started to program in GD2 colours, the possibility of upgrading EasyPtr was raised including a lot of discussion on this list. Just out of interest Marcel took a look at it and working through the night produced a version that could use GD2 colours directly. He sent copies to one or two people whom he knew were actively attempting to write programs in EasyPtr using the colours. I put "beta-testers" in inverted commas because this was probably not their intended role. At this stage there was some doubt over the legal position, which in itself led to a lot of misunderstanding because no one had thought of asking Albin. I understand that he is quite happy for the program to be upgraded. When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. This can be a bit of a pain in the neck if you have a lot of sprites in a program. (And we should remember that the new sprite technology means that we should be wanting to include more sprites and more sophisticated sprites in our programs.) I am not sure what changes have been made to the upgraded EasyPtr since I last saw it, but I can understand if Marcel says it is not yet ready for release. We have come to expect a high standard from Marcel, and thus we should respect his opinion on this and not pressure him to release an incomplete product. It would be helpful if we could have an indication how far EasyPtr has developed and what is left to do. Then the sort of suggestions that Per made could be considered. BTW this is just the sort of topic that could be discussed at Eindhoven on 18th June if we are successful in getting the After-Glow Show off the ground, Best Wishes, Geoff ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
In message <[EMAIL PROTECTED]>, gwicks <[EMAIL PROTECTED]> writes At this stage there was some doubt over the legal position, which in itself led to a lot of misunderstanding because no one had thought of asking Albin. I understand that he is quite happy for the program to be upgraded. Jochen and I have never had any doubts over the legal position because Albin handed control of over to us. He did, at the time say, he would reassume control when the colour drivers cam out but that tool too long and he is now out of the mondset which created it. When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. This is true and I am not sure how they would work when that menu was used. I have been experimenting with it myself recently because I have updated my Invoicing program. I find I cannot get high colour sprites to stick. Marcel had a look at it for me but said : ''Well, as far as I remember the whole object code is a complete mess, I'm not surprised it isn't working... I tried it with the example file above, but even though the sprite is loaded again Sysmon starts beeping, so doesn't work too well either.' I would be happy to release the version I have here as a free upgrade but we are not sure of the stability of it and it does have the above problems with the icons. That said I will ask him if I can release the version I have to registered users and include it as a high colour option on the distribution disk. I know he does not want work on this so I doubt there will be another version unless his curiosity gets the better of his judgement and he pokes at it some more. We have come to expect a high standard from Marcel, and thus we should respect his opinion on this and not pressure him to release an incomplete product. I completely agree. I also agree with previous comments about producing menus by non graphical means. EASYPTR was the best way to make the menus in spite of its obvious drawbacks in other areas. -- Roy Wood Q Branch. 20 Locks Hill, Portslade, Sussex.BN41 2LB Tel: +44 (0) 1273 386030fax: +44 (0) 1273 430501 skype : royqbranch web : www.qbranch.demon.co.uk ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
gwicks schreef: >SNIP> When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. This is not true. Once your window is ready, save it in the usual way. Create your XXX_cde file (ptrmenr_cde, window definition designed with Easymenu, and add all your sprites ). Of course the sprites have to be in the correct order (first sprite for Loose Item -1, 2nd sprite for Loose Item -2, and so on). In your Sbasic program you could do something like this: (extract from my Front End for DBAS) 230 MDRAW#3,mysuqces$ :REMark mawdraw#3,4 280 FOR xx= 30 TO 1 STEP -1:MITEM#3,-xx,-2,SPRA(xx): :END FOR xx:MLIDRAW#3 Et voilà. Of course you wouldn't see those sprites next time you load EasyMenu to modify a menu but you don't have to reload them each and every time. Mind you (correct English?) EasyMenu is not very good at displaying high colour sprites, you have to fool it by putting a 4/8 mode sprite in front of each high colour sprite. This can be done with a small sbasic program Wolgang Lenerz published somewhere (on this list or in QLToday).It is about 20 lines long and is called 'chainsprites_bas'. I have created tens of sprites with this method. I have been using this for quite some time now, even in my Email reader. Easymenu can do much more than we first thought. It would be helpful if we could have an indication how far EasyPtr has developed and what is left to do. Then the sort of suggestions that Per made could be considered. BTW this is just the sort of topic that could be discussed at Eindhoven on 18th June if we are successful in getting the After-Glow Show off the ground, That would be a good idea! Best Wishes, Geoff François Van Emelen ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Geoff Wicks wrote: As I understand it the history is as follows: When QL-ers first started to program in GD2 colours, the possibility of upgrading EasyPtr was raised including a lot of discussion on this list. Just out of interest Marcel took a look at it and working through the night produced a version that could use GD2 colours directly. He sent copies to one or two people whom he knew were actively attempting to write programs in EasyPtr using the colours. I put "beta-testers" in inverted commas because this was probably not their intended role. At this stage there was some doubt over the legal position, which in itself led to a lot of misunderstanding because no one had thought of asking Albin. I understand that he is quite happy for the program to be upgraded. When I last saw the upgraded version all it did was allow you to use GD2 colours directly, but nothing else. For example, if you use high resolution sprites you have to load these into EasyMenu every time you make changes to a menu. This can be a bit of a pain in the neck if you have a lot of sprites in a program. (And we should remember that the new sprite technology means that we should be wanting to include more sprites and more sophisticated sprites in our programs.) I am not sure what changes have been made to the upgraded EasyPtr since I last saw it, but I can understand if Marcel says it is not yet ready for release. We have come to expect a high standard from Marcel, and thus we should respect his opinion on this and not pressure him to release an incomplete product. It would be helpful if we could have an indication how far EasyPtr has developed and what is left to do. Then the sort of suggestions that Per made could be considered. BTW this is just the sort of topic that could be discussed at Eindhoven on 18th June if we are successful in getting the After-Glow Show off the ground, Best Wishes, Geoff Well said as usual Geoff. I hope that any update to Easyptr would allow some changes in the colour handling on the toolkit extensions side as well. It would be useful if menu colours could be made to assume the new Window Manager colours in some form (standard appearances and all that), e.g. specifying a negative colour number or some special setting picked a standard window manager colour scheme or whatever. I haven't thought this through, I don't even know if it's possible/desirable. It would be useful if the menu colours could be changed at runtime. At the moment, once they are defined in the Easymenu layout, that's it, the colours are fixed unless you manipulate the colour palettes or whatever. It might be possible to hack around in the working definition to set the colours if someone was prepared to write such extensions, but I don't know if this sort of code could be achieved legally. The nice thing with Easymenu in particular is that you can just visually create menus without worrying too much about endless lists of data as you have to with some other older PE development tools. If you want to explicitly set loose item, menu, or window sizes you can do so, but don't have to. If you want to, you can just size them by appearance, especially if you use text loose items when you don't have to worry too much about pixel perfect fit and endless lists. We would need to get the resize flag mechanism implemented too, although there is an extension by Per Witte which will help with that for existing menus if you are prepared to play around with the working definition a bit. Which sums up the existing Easyptr - you have to think laterally and go the extra mile to achieve anything useful (ref. Wolfgang's colours article in QL Today Vol 8 Issue 5 page 8). Since Easyptr will probably be the source of the majority of any new applications, effort deserves to be focused on that a bit I'd have thought. I do hope that development does get going though, even if it turns out to be easier to write a similar new product than trying to rehash uncommented old code or whatever. -- Dilwyn Jones -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.6.2 - Release Date: 04/03/2005 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Am Sat, 5 Mar 2005 21:20:03 - hat Dilwyn Jones <[EMAIL PROTECTED]> geschrieben: It would be useful if menu colours could be made to assume the new Window Manager colours in some form (standard appearances and all that), ... They can, no problem about that. It would be useful if the menu colours could be changed at runtime. At the moment, once they are defined in the Easymenu layout, that's it, the colours are fixed unless you manipulate the colour palettes or whatever. Sorry, but this is nonsense! Except for the "main window" you can change colour and ink of ANY window from within a program. Just use "MWINDOW"! Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
Am Sat, 05 Mar 2005 22:08:04 +0100 hat François Van Emelen <[EMAIL PROTECTED]> geschrieben: 230 MDRAW#3,mysuqces$ :REMark mawdraw#3,4 Oh Francois, what's that? I don't know but one SuQcess and that's the one of me and Bob Spelten ;) EasyMenu is not very good at displaying high colour sprites, you have to fool it by putting a 4/8 mode sprite in front of each high colour sprite. This is not true! Only if you want to have the sprites in mode 4 or 8, too. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
gwicks wrote: > At QL2004 I asked Marcel specifically about his attitude to the EasyPtr > upgrade and he was quite definite that he did not want to be seen as "Mr. > EasyPtr". I interpreted this to mean that he does not want to be seen as the > solution for every problem that arises in the QL community. I can sympathise > with him on that. Thanks. It shows time and again that as soon as you touch something you become the one that can be bugged with all questions and problems regarding it and this is something I'd very much like to avoid this time. If I release a new version it would be strictly under an "as-is" term. Problem is that, as it is, I'm quite busy. E-Mails are piling up (sorry for the delay, WL) and even things that have been completely coded like QPCPrint are not shipping yet because worlds lie between having the code ready and having the product ready (manual, installation procedures, web site... basically all things I hate doing). The EasyPtr code is difficult to say the least. If somebody is willing to take it over and REALLY work with it... drop me a line. I have said I will try to do more work on EasyMenu and after reading the discussion yesterday I've been playing some more with it (even though I should have a much more important project ready by Monday. Looks like a busy Sunday, I guess :-( ). I got a new version that should be able to handle all the new GD2 sprite variants. It will probably need a new SMSQ/E release, though, so inquiries at this time are futile. That said, I'm no EasyPtr user anymore (haven't been for 10 years), so for those who have been using the release, what else is not working correctly? Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [ql-users] EasyPtr was movig sbasic
gwicks wrote: > At this stage there was some doubt over the legal position, which in > itself led to a lot of misunderstanding because no one had thought > of asking Albin. I understand that he is quite happy for the program > to be upgraded. Yes, he basically said that anything I choose to do is fine with him. > When I last saw the upgraded version all it did was allow you to use > GD2 colours directly, but nothing else. For example, if you use high > resolution sprites you have to load these into EasyMenu every time > you make changes to a menu. Right. It was able to load the raw sprites, because then it just took that junk of memory, but when embedded into a menu it tried to make a copy of it and of course completely failed. > This can be a bit of a pain in the neck if you have a lot of sprites > in a program. (And we should remember that the new sprite technology > means that we should be wanting to include more sprites and more > sophisticated sprites in our programs.) Actually that was part of the problem. The sprite definition became so complex that it was a pain to support it for EasyMenu. As said, I have done most code now (which should ultimatively be part of SMSQ/E so others in this situation don't have to do it again), but it is not debugged. > I am not sure what changes have been made to the upgraded EasyPtr > since I last saw it, but I can understand if Marcel says it is not > yet ready for release. We have come to expect a high standard from > Marcel, and thus we should respect his opinion on this and not > pressure him to release an incomplete product. That's exactly the point. At least without working sprite support it was just a nice toy, not fit for anything really. With it, it looks somewhat better. But I do have high standards for myself, especially if ever any money would change hands for it. Marcel ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
