Register to post in forums, or Log in to your existing account
 

This forum is locked: you cannot post, reply to, or edit topics.  This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion Goto page 1, 2  Next
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Mar 29, 2005 3:35 am   

Build 2.2.0.25 posted
 
I have posted a new build of zApp today. I've been focusing on the Grid functionality. I haven't started documenting it yet (will start that tomorrow), but a lot of functionality is working.

To demonstrate some of the functions, I have also added a new demonstration program. It's called the Game of Life and is an implementation of the classic Conway's Life simulation cellular automata program.

I've posted the source code over in the zApp Demos area. A lot of the script is used to compute the next generation of the pattern, and is pretty hard to read. I optimized it to get more performance compared to something that was easier to read. Basically, to computer the number of neighboring pixels, it uses three running sums that are updated as you go across a row. And rather than calling other subroutines, everything is stuck inline.

The performance on my fast computer was reasonable, but it also shows the speed limits of scripting languages. Enough to play around with, but a "real" program would implement the main function in a compiled DLL for more speed.

But it demonstrates how flexible the zGrid component is. Instead of the standard data-aware grid, or report grid, the grid is used in this demo as an array of pixels, mapped to a couple of arrays in the script. When the arrays in the script are updated, the grid is refreshed. Check it out...it's pretty cool.

I was a bit disappointed that the DevExpress grid doesn't have "block selection" by default. I found some routines that add it and I'm going to play around with that. I think it would be cool if you could copy/paste blocks of pixels, or save/restore patterns to the clipboard.

Right now, clicking with the left button sets the pixel, and clicking with the right-button clears the pixel.

You'll also see that this demo uses the new TIMER component. I was originally going to use the THREAD component in this demo, but a script in a different thread can't communicate with anything in the main script, and since threads are in different memory spaces, you also can't assign an array in a thread script to a grid in the main application. It's just the way threads work in Windows (they are highly constrained). But the timer method seems to work just fine.

Have fun! More stuff coming later in the week.
Reply with quote
The Raven
Magician


Joined: 13 Oct 2000
Posts: 463

PostPosted: Tue Mar 29, 2005 6:55 pm   
 
Perhaps I'm looking in the wrong spot, but I just checked and see no new build in the Downloads... 2.0.0.20 is the one available on the zApp downloads page.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Mar 29, 2005 10:34 pm   
 
I just forgot to update the Download page. It's something I haven't automatted yet and sometimes after doing the FTP upload I forget to go into the MX-Portal config to update the version string for that file.

Anyway, I just updated the version string. But the file was always there, so if you downloaded it today then you got the 2.2.0.25 build.
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Wed Mar 30, 2005 2:09 am   
 
Heya Zugg,

I been lurking a bit the past few months (little time to test out new stuff) but some time did come to me yesterday, and I went to the download page and I was like 'Kahzah! What in the world!?' and I'm by far not your 'average joe' user..however I was LOST as to what I'd have to download to get running.

I understand theres a pro edition and a runtime...But..uhh..there were like 4 files there? Also, can't they all include the runtime?

thanks,
Krule
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Mar 30, 2005 2:51 am   
 
I think it is pretty well explained on the first page of the zApp Manual.

  1. The free runtime version. This will execute any binary ZXL application
  2. The licensed end-user edition. This will execute any binary ZXL application, along with any text ZML application or plugin.
  3. The Pro edition allows you to create the encrypted binary ZXL files from their ZML text version. This requires the End-User edition.
So, there are really only two versions: the free runtime, and the licensed end-user edition. The Pro product is a zApp program that needs the end-user edition in order to run.

There is no way for the end-user edition to "include" the free runtime. The free runtime is essentially a subset of the end-user edition, with the text ZML functionality removed.

If you buy the end-user edition, then you never need the free runtime version. As I mentioned, the free runtime version is a *subset* of the end user edition.

On the download page you will also see the Weekly CVS build of the end-user edition. This is only intended for people who really need the latest (potentially buggy) version and should never be downloaded by anyone that doesn't know what they are doing.

Anyway, I think the web pages are pretty clear about all of this if you read them carefully.
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Wed Mar 30, 2005 4:08 am   
 
Oh, don't get me wrong, I figured it out myself...

I'm just concerned that average joe users might get confused upon first approach to that site..maybe it was just me...I wasn't trying to be unnecessarily critical.

Sorry if it seemed that way, I'm just trying to help you in any way I can, I figured feedback from a user POV would be an asset.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Mar 30, 2005 6:09 am   
 
Well, I appreciate the feedback, but I just don't have any clue what to do about it. When you go to the main http://www.zuggsoft.com/zapp page for zApp and click the "Learn More..." link you get a page that fully describes the 3 versions. When you go to the Download/zApp page, the description of each file tells you what it does (free runtime can execute binary files, end-user can execute binary and text files, pro version requires the end-user version, etc).

I guess if you had more specifics on what you think I should do then maybe I can improve this. But as it is I'd say that all of the information is already there.
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Wed Mar 30, 2005 9:41 am   
 
I might have a suggestion. Dumb it down it bit and give an example of what each is used for, how each might be used by a particular type of person (developer, emobius user, penniless teenager with a neato compiled dll, freshly downloaded from www.hackersRus.web

It may be too early still to worry about it, but if average Joe is told to download zApp so he can play this neat game, work on a database, etc., he probably would be a bit confused by all the developer lingo. If the front page said something like:

"This free runtime is the only thing required to ..."
"If you want to customize the look of your program and you're comfortable editing an xml text file then the end-user edition is right for you."
"Along with the end-user edition, zApp Pro will let you create ..."

If I'm the average Joe and I'm told I need to download zApp to run a cool application, I should be able to determine which version I need fairly quickly (first page) I think, even if the information I had received wasn't complete or obvious.

Average Joe has no idea if he needs his binary files executed, his text files decimated or his digits manicured. I think this is what Krule meant.

I'm not trying to be critical either. I've been reading the forums for a long time and I understand what's going on to some extent. If not for that, however, I'd be totally lost looking at that page. We're just trying to help. Cool
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Wed Mar 30, 2005 1:20 pm   
 
Yeah, he definatly expressed what I was trying to in a better way :)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Mar 30, 2005 6:23 pm   
 
OK, I'll see what I can come up with. I might also do a page called "What version do I need?" with some sort of matrix showing what each version is for.

One thing I need to keep in mind though is that while I need to give an easy download link for people who need the free runtime to run some 3rd party app, what I *really* am trying to do is sell more copies of the end-user edition and encourage people to customize their apps and write plugins.

Usage of the free runtime doesn't necessarily drive sales of the end-user edition because the audiences are so different. Right now I guess I'm concentrating more on trying to get developers interested who will actually buy this stuff and write apps with it.
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Thu Mar 31, 2005 8:40 am   
 
Zugg wrote:
Right now I guess I'm concentrating more on trying to get developers interested who will actually buy this stuff and write apps with it.


Yep, that's understood. No immediate need for catering to the lowly user -yet.

My concern -and reason for posting- was that; while developers WILL pore over a web site, many levels deep to get information about an application they're using or considering, end users look at programs as pass/fail for the most part and unless it's spelled out for them, they won't try too hard to make it work.

Finally, "end-user edition"? I believe it may be asking too much to to get Average Joe's head around that.

Because we have trite modifiers for software, Average Joe would understand at a glance that "zApp-Lite", "zApp-basic", or even "zApp-barebones" is less powerfull and hopefully less appealing than zApp("+" or "plus"), Basic-zApp, or MYzApp.

"zApp Pro" is good enough as it is. But perhaps because it is really a separate entity it needs a separate name? zApp Pro isn't really zApp since you need the 'end-user edition' to do anything with it. *shrug* Maybe "DEV-zApp", or "zYggle" (any made-up name will do) would help distinguish this application as something not-quite-zApp.

Like I said, this isn't something that needs to be a concern yet; keep developing toward eMobius please. But, perhaps this is something to let percolate the nether regions of gray matter while pressing ahead with coding.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Mar 31, 2005 9:54 pm   
 
Yeah, stuff like zApp-Lite and zApp-basic don't work, because that would be confused with the "free runtime" which *is* a "lite" or "basic" version of zApp.

So maybe we need the end-user version to be "zApp Pro" and then rename the developer's tool to "zApp IDE" or something like that which the developer's would understand but the regular users wouldn't care about.

And yeah, I need to get refocused on eMobius. This zApp stuff could keep me busy for years. I've gotten side tracked on all sorts of little details this week as I try to get zApp into public release shape.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Thu Mar 31, 2005 11:29 pm   
 
*grin* I want my email client! ;)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Apr 01, 2005 12:59 am   
 
Me too!!!!

But stuff is just taking forever. For example, for a public release of zApp, I want all of the various popup dialogs to be properly themed. Well, the ThemeEngine comes with stuff like a FileOpen box, but it's horrible. Half the stuff people are used to using in a FileOpen dialog just don't work. Delphi just calls the standard Windows dialog, which can't be themed.

DevExpress has good Shell controls, so I decided to make my own themed FileOpen dialog. It took 2 days!!!! to do this and get it working. All for this silly dialog box.

Now, it *is* cool because the pull down box above the file list (the ShellCombo box) in DevExpress is a full tree view. So, you can pull down this list and navigate to any directory, as opposed to the "standard" Windows dialog where the pulldown list only shows the top level of folders along with the currently opened folder path. I've always hated that pulldown...it is worthless.

Also, with the DevExpress stuff I was able to add a "hidden" folder tree that you can click a button to display just like in the normal Windows File Explorer. It also supports the full right-click context menu, and has useful mouseover hints. So, I ended up with a really nice FileOpen dialog that I can completely customize to work how I want it.

But I was still amazed it took two days. Definitely wasn't something that was on my schedule to spend that much time on. And that's just one of many dialog boxes.

All of this stuff will be useful in eMobius, but there is just *so* much to do. And I'm working 10 hours a day, 6 days a week, for the past 5 weeks like this.

Too bad I just can't make a bunch of clones of myself.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Apr 01, 2005 1:02 am   
 
Oh yeah, here is something else that's *really* scary. When I do a full build of zApp, which compiles all of my code, plus all of the 3rd party code (like DevExpress, but not the Dephi internal stuff), zApp has now exceeded one-MILLION lines of code!!!

Be afraid...be very afraid...
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Fri Apr 01, 2005 2:02 am   
 
crikey, I suppose 1 million lines in 6 months isn't too shabby an effort for 1 person ;)
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Fri Apr 01, 2005 2:30 am   
 
Although I am looking forward to eMobius I am anxious for zApp to reach the point where it has all the functionality and stability I need in order to publish some titles developed in it.

I have been sick the past week so I have not been able to work with the latest build although I did look at the Game of Life that Zugg wrote (which makes zApp an official development environment now Very Happy ) Nice!

I realize there are limits to what Zugg can do for zApp because he wants to get eMobius done but zApp is almost to the point where I can develop the applications I was planning on developing.

Zugg, the only thing I hope you will be able to add is the scrollable view area. This will be used for my second project (the TCS) so there is no super rush for it but I think that project has a lot of potential.

How close are you to being done exposing all the properties and methods for the Treeview, Grid and Richedit controls? (No rush, just wondering Wink)

You are doing great work, Zugg! Keep up the good work.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Apr 01, 2005 3:45 am   
 
You'll be happy to hear that the scrollable panel is in the next build. Also, you'll be *very* excited to hear that the Web Server component is also in the next build, along with a new HTTP server demo app. It's simple but works very well.

The properties and methods of the Tree and Grid components are pretty good. The Tree is all documented already, so let me know what you think. The Grid should be documented later this week. The RichEdit component is the next one to tackle, which will probably happen next week.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Fri Apr 01, 2005 6:12 am   
 
Oo-er, web server component sounds interesting. Hmm, wonder who will write the first MUD using zApp ;)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Apr 01, 2005 6:49 am   
 
Heh, it's a scripting language, so I doubt anyone would use it for anything that required real performance, like with a MUD. But it had enough interesting uses that it was useful to add. Plus, adding it was easy since the Indy components are very robust and easy to use.
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Fri Apr 01, 2005 2:18 pm   
 
You're awesome, Zugg!! Extra servings of delicious low-carb food for you!!
Reply with quote
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Fri Apr 01, 2005 7:12 pm   
 
Rainchild, that would be cool as a technology demo, though. Cool
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Apr 02, 2005 12:50 am   
 
Well, unfortunately it's going to be a few days until the next release. I ran into a major annoying problem today.

Somewhere in the changes that I made in getting the DevExpress stuff using the ThemeEngine core, I added a dependancy that made the DevExpress components stop loading into Delphi.

If you have used Delphi, you'll know that one of the huge headaches is dealing with "Packages". Packages are essentially DLL files that contain 3rd party components. You install a Package into Delphi and the components are added to the toolbar.

Once added to Delphi, if you have the source code for the components, you can actually change the source code and compile your apps, even without rebuilding the package. The Delphi smart Linker will always link in the most recent version of the particular module.

However, once something gets screwed up, then Delphi can decide that the package is no longer valid and will refuse to load it. And now any application that uses this package won't load into Delphi either.

When you have dependant packages, it becomes a real pain. One screwup and Delphi can decide not to load all of the dependant components. That's what happened to me today.

The problem was with the core ThemeEngine stuff which mimics the Microsoft uxTheme.dll file. I had modified DevExpress to use this part of ThemeEngine, but now Delphi wants to load the entire Theme engine package before I can load DevExpress.

What makes me really mad about this is the idiot who wrote the ThemeEngine code put most of it into ONE BIG FILE! No modularity at all! So, I just spent most of the day splitting the ThemeEngine into pieces. I'm created a ThemeEngine_Core package that just has the core theme stuff, without any of their crappy controls. Then, I tried putting the "Form" control into it's own file (this is the control that handles the border, window caption, etc, which I still need in zApp).

Well, the ThemeEngine_Form control turns out to be dependant upon all sorts of other crap. It's going to take a while before I get this all sorted out.

Right now, I've been able to get the DevExpress controls loaded back into Delphi. So that's a good first step. But now, I am forced to go to all of my dialog boxes (like the RichView dialogs, the spellchecker dialogs, etc) and remove all references to ThemeEngine controls and replace them with references to the DevExpress controls. Once this is done, then I can load those 3rd party components into Delphi too.

So, the objective at the end is to have everything loaded into Delphi, *except* the ThemeEngine controls themselves.

Unfortunately, while I'm in the middle of this, I can't build zApp. And unfortunately the nightly build last night also failed (probably because of whatever caused all of this trouble in the first place). So, even though I had a nice build yesterday with the ScrollPanel and HTTP server, I won't be able to rebuilt zApp and upload the new build until I get this whole new mess sorted out. Since I'm gone most of this weekend, you won't see the new build until early next week.

It's really a shame that I started using this ThemeEngine crap in the first place. If I had just started my own core engine from scratch, I think I would have been better off in the long run. That's essentially what I'm ending up doing now, but if I had done it 6 months ago when I picked the theme components, I would have been better off I think. I've rarely seen code worse that this stuff. It's painful to work on.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sat Apr 02, 2005 4:45 am   
 
I commiserate with you, Zugg. There have been many times in the past when I thought I could do a much better job if others simply wouldn't get in my way. In general though, I think we both need those fellows to blaze a trail. Even if that trail is shoddy and full of pitfalls; it paints a possible path amongst the myriad of possibilties. Some of them might even be more fraught with peril, and a few of those might hide the peril better then the path that was blazed in failure. All told, I can never fault the man that tries to create a whole new path. I think the Theme Engine stuff did just that, and that is what attracted your attention in the first place.

Since then you have found the faults; but to be realistic, had you tried to write it all from scatch you would have made the same mistakes. The only difference being that you would have been more readily capable of correcting your mistakes then his. Yes, a lack of modularity is frustrating. There is no reason to not do this these days, linkers take care of nearly all the mess created by seperating code that is bi-dependent on other portions. Even if there is no way to seperate the sections, you shouldn't be left feeling like the software you paid for is crap. I am sorry to hear how much of a set back the Theme Engine stuff has become when you were happy about how it advanced things before.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Apr 02, 2005 6:37 am   
 
That's actually very true. zApp probably wouldn't have theme'ing at all if it wasn't for the ThemeEngine ideas. And yes, it's complicated enough that it would have been a big job to write it myself from scratch.

I think what frustrates me the most is just the overall bad coding style. It's all brute force, hacked together. For example, instead of making a subroutine that does a common task, it looks like the same code is just copy and pasted over and over again with small modifications. It's the kind of stuff that really aggravates a "traditional" programmer, like myself, who was raised to care about code efficiency. And since the author isn't supporting the product, I know that I'm stuck with it myself and have to mold it into something that I can support over the long haul.

My big worry is that it will be this mess of code stuck in zApp that I'll always be "afraid" to work on. There are some pieces like that in zMUD (and some that even I am responsible for originally writing I admit). Having parts like that in a big project like this can become a real mess if I don't deal with it now. So it's really important that I do it "right" this time so it doesn't come back to haunt me.

My current strategy for this is to completely minimize the amount of ThemeEngine code that I use in zApp. I've been really impressed with the DevExpress source code, and their support, so I'm trying to use as much of that as possible, and as little other stuff as I can get away with. That's exactly why I didn't just load all the ThemeEngine stuff back into Delphi in order to get DevExpress to load. I don't want the DevExpress stuff to depend upon the ThemeEngine code, or to only depend upon a small core piece.

Anyway, I had some more protein so I'm feeling better about this all now. It's the right thing to do and I was going to have to do it eventually anyway. It's just as well that I have to do it sooner rather than later. It will make the public release that much better.
Reply with quote
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
© 2009 Zugg Software. Hosted on Wolfpaw.net