Zugg Software :: View topic - zApp and eMobius plans for August (and wish list)

Posted: Fri Jul 22, 2005 5:28 pm

I've had some time since the Shareware conference to really give all of this some serious thought. Part of me wants to get started on the eMobius email client. Another part of me wants to give zApp a chance to be a successful product.

One of the things that I realized was that when you currently install zApp, nothing actually happens. Sure, it runs the demo.zml file, but that isn't very exciting. zApp itself is really more of a runtime...you have to open an editor like Notepad, enter your program, then run it with zApp.

So, for a new user who downloads zApp, they don't see much. If they don't already understand what it is, then they will never try to run it or buy it. They'll probably just delete it.

As some people have mentioned in the past, what zApp really needs is a basic IDE. I need to take the zAppPro editor and distribute the base editor environment with zApp and have that editor start after you install zApp. Then when you try to access the Encrypt or Link options in the IDE, it would prompt you to upgrade to the zAppPro Developer's version. This would also help promote zAppPro within zApp itself, and is something that is easily doable with the new ecommerce system I'm looking at.

I'd really like to give zApp a chance to succeed. When I had a chance at the Shareware conference to explain what zApp was, people seemed to be excited. But it's hard to explain zApp in one simple sentance...it needs real marketing. And while I think the web pages are getting better and might encourage people to download the product, the product just doesn't sell itself once it is downloaded.

zApp still needs several features in order for me to use it to write the eMobius email client. It needs the window-docking code to make dockable windows, and it needs to have a better way to handle a large application like eMobius while encouraging modularity (an enhancement to the current plugin architecture).

Since I obviously need to spend some more time working on zApp coding before eMobius, I've decided to continue spending time trying to market zApp. I'm going to try and get zApp posted or reviewed on various software development sites, especially sites geared for more traditional developers who used older versions of Visual Basic who are disenchanted by the .NET direction that Microsoft has taken.

I'd be interested in your comments on this. Also, please use this thread to post your "wish list" for zApp. In other words, post those features that you'd really like to see me add to zApp to make it a more viable development system. (I can hear theNerd typing already ;)

I know I keep postponing eMobius. Who knows, maybe it's a sign. I still want a better email client myself, so I'm sure I'll eventually get to it. But the universe seems to be pushing me more in the direction of zApp right now and I feel like I need to give it a chance.

Posted: Fri Jul 22, 2005 7:32 pm

Since zApp is the runtime, I would say to leave out any sort of IDE. You being one person, I would like your energies spent on zApp Pro, when it comes to development aids.

As a suggestion, I would like to see some sort of dialog when zApp.exe is started without parameters. Something to the effect of "zApp does not have anything to run at this time. However several demos are available for you to try." Then have a button for each demo file found, so that I don't have to hunt them down.

Also a hyperlink in the dialog that says something like "Click here to see a tutorial on zApp" that will take users to a web page with tutorials.

Posted: Fri Jul 22, 2005 8:14 pm

Actually, zApp already does that. If you run zApp without parameters you get a File Open box to select a ZML or ZXL application. Unfortunately, I'm still not sure this will help people much.

Maybe I wasn't clear though...what I mean is that I'll be working on the zApp Pro IDE. And then the regular version of zApp will include a "lite" version of this IDE. With the tools I have now, I can create a single IDE that has "Lite" and "Full" functionality unlocked with various license codes.

Put yourself in the shoes of someone who doesn't know what zApp is. Either a need a much better demo program, or I need the IDE to be displayed when you run zApp. Maybe just a much better demo program would also fit the need. But in any case, *something* is needed over what we have right now.

Newbie Joined: 25 May 2005 Posts: 4

If you could write the IDE itself in Zapp, then that might be a good sales point as to a demonstration of what Zapp is capable of doing. It also might make a pretty nice source code example if you didn't mind making it available (although that might invite too many license hacking attempts).

Mark

Posted: Sat Jul 23, 2005 5:55 pm

Yes, most of the zAppPro IDE is written using zApp itself. If you download zAppPro you get the ZML source code for it already. I intend to expand upon that so that the main IDE is easily customizeable.

Adept Joined: 01 Mar 2005 Posts: 277

Wow! I can't believe I'm not the first to reply to this thread! Laughing

Zugg, your idea is a very good one. I have tried encouraging many non-programmers (those with some experience with HTML but little else) and full-fledged developers to give zApp a try. I believe it can appeal *very* easily to both groups. What is missing - especially for beginners - is a basic but intuitive IDE. At this point the average person will install zApp and then say to themselves, "now what?" Think about it. Many people create web pages now but they're being done in FrontPage and other WYSIWYG editors. Very few are willing to do it in notepad. The truth of the matter is, is the IDE becomes the "face" of the language. It represents it. I like the idea about the 2 IDEs - the basic one and the advanced Pro one.

Zugg, I am very willing to re-talk to fellow devlopers and others I've spoken to regarding zApp after an easy IDE is put together and get them to re-try it.

Also, I have to tell you how excited I am that you are willing to focus on zApp since I believe it has a lot of potential. I am also very excited about the affiliate program so I can sell the runtime directly from my web site. That would make it much easier for my customers.

As a side note to point out zApp's marketing potential, I'd like to point out your competitions greatest weakness - the huge runtime. Amazingly, there are many developers who have bowed to pressure from Microsoft's marketing muscle and are developing in .NET. The new mantra (repeated in a zombie like fashion) for .NET developers is that eventually everyone will have the huge .NET runtime on their computer. What they fail to realize (or admit to) is that that is quite a ways away. Asking my customer to download my 20MB .NET app on top of the .NET runtime could scare away potential customers. Also, keep in mind that the .NET runtime is like any other bloated Microsoft product, it has perpetual updates and patches. A fellow developer I work with told me his .NET runtime is now over 100 MB! The zApp runtime is *extremely* small in comparison.

I am going to go ahead and make a second post with my suggestions in order to keep the posts simple. Razz

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

I know that this is probably not an easy task, but perhaps coming up with a timeline of some sort for both zApp and eMobius (a la mozilla). I'm personally more interested in eMobius..but I understand that in order to develop eMobius, zApp needs to mature...but it'd be nice to see some milestones, ish.

Adept Joined: 01 Mar 2005 Posts: 277

Okay, you asked for it: Laughing

* Outlook style bar
* Minimize to system tray (with right-click menu and pop-up balloons) so I can run apps in the background
* MUD client control (I think some zMUD users would like this added)
* Versatile sprite system Razz (I wouldn't mind creating some game and/or education software in zAPP)
* Good sound engine
* Canvas for drawing, etc. (make sure I can read the hDC for this to pass to AcitveX or DLLs.)
* Docking windows and toolbars
* Ability to use non-ActiveX DLL's
* Easy printing of Grid contents
* A WYSIWYG interface designer (Zugg, don't slap me for suggesting that Razz

)

Posted: Sun Jul 24, 2005 3:37 pm

theNerd's list is just about right. In addition to those features in zApp itself, I'll need to do the basic IDE, and that includes some of the WYSIWYG design stuff that theNerd mentioned. If you have ever used a product called RealBasic, you'll have some idea of a simple IDE interface. Not as complex as Delphi or Visual Studio, but very functional.

The IDE will be similar to an HTML editor in that you'll have a tab for the "visual" interface where you can drag components around (drag buttons and edit boxes into the place that you want them, and then manipulate properties in a property-editor panel), and also an "XML" tab where you can edit the XML code directly. Changing stuff in one tab will change it (or regenerate it) in the other panel. Then a quick Run button for running the app, and a Sandbox area where you can just execute zApp scripts to play around with stuff.

As far as what things eMobius needs: the Outlook style bar, minimize to system tray, docking windows are definitely needed. Along with a better structure for managing "projects" of multiple files (eMobius will have lots of dialogs and windows). The IDE would also certainly make eMobius development easier also.

For a timeline, I always hate to make any promises regarding timescale. Things always take longer than I expect. I'm guessing that zApp needs at least another month's worth of programming. That's assuming I don't run into any problems.

For eMobius, the timescale is even harder. I'm having trouble determining what features are needed for the first release. I've mentioned this before, but the problem with eMobius is that everyone has certain expectations of what an email program needs to do, and different people have different expectations. If the first version of eMobius doesn't deliver on these expectations, then some people will just dismiss it. It's a lot harder to deliver a "basic" version and then update it over time. I'm guessing that I'll have to start small and work with a private set of patient beta testers on the initial versions. But I'd still hope to have a first version sometime this Fall.

Adept Joined: 01 Mar 2005 Posts: 277

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

I don't think you've added a timer control yet (don't see it under Visual Object Reference, Non-Visual Object Reference, COM Objects, or Core Library).

The grid control could use some extensions (or does it already do some of these?):
1) more flexible headers (more than one row/column, ability to merge cells, etc.)

2) It can export to a good number of formats, but for printing something like a metafile would be nice (ditto for other visual controls).

3) I don't see in the documentation if there's a way to set the text alignment on a per column or cell basis. That's important for numbers, like money: you want to right justify so that the dollars and cents line up. All I can find is the common property "alignment", but the help only discusses windows and controls.

4) When editing is turned on for the grid, it would be very helpful to be able to turn off editing for individual cells, or at least rows/columns. You can edit the amounts of transactions in a checkbook register, but you shouldn't be able to edit the "Total" in the bottom row.

The IDE will help a lot. So will more extensive examples- you include a good variety of types of applications, but a series of demos that really give each component a workout of basically all methods and properties would be great.

Release of eMobius, or some other commercially successful app, would also really help push zApp.

-Tarn

Adept Joined: 01 Mar 2005 Posts: 277

I'd also recommend (and I am sure you thought of this anyways) that when these new changes are completed you reset the 30 day limit so some of those who have tried it before can try it again.

Posted: Mon Jul 25, 2005 4:06 pm

Yes, there is already TIMER control. But you are correct in that I seem to have forgotten it in the documentation. For an example of using it, see the Life demo program. Also, you can use the existing THREAD component in a timer/alarm mode.

1) I'll add that to my list and see what is possible. The current grid control is very powerful and it's a challenge to access all of it's functionalities. But ultimately it's still a "grid" control, and not an HTML table, so I'm not sure what I can promise on this. But I'm hoping that stuff like merged headers are possible. Not sure about merging cells though. I'd need a more concrete example of what you are really trying to do with it.

2) We'll have to see about printing...that can get very tricky. I know the DevExpress system has a big printing engine for the Grid controls, but it doesn't handle other controls. Delphi has a way to print a "form" if that's all you are looking for. So I might be able to do something crude like that. The Memo control already supports printing, and that's where most people will be printing from I think.

3) See zColumn.Align As the help mentions, it controls the alignment of a column. The cells are controlled by the column so there currently isn't any way to change it on a per-cell basis, and I can't think of an application where you would want to do that.

4) You can control the editing on a column basis using the zColumn.AllowEdit property. For a "Total" row at the bottom, it would be better to use headers/footers, and I need to make the footer and summary rows available via scripting. That kind of stuff should definitely be possible to add. A checkbook program is a great example of using a grid, and anything you need for an application like that should be doable.

As far as the 30-day trial, yes it will definitely get reset when I switch to a different copy protection system. You should see that within a month.

Posted: Mon Jul 25, 2005 7:46 pm

Another item I'm adding to the To-Do list is supporting Drag/Drop events. This is needed for eMobius in order to drag messages from the Grid display into the Tree display.

Adept Joined: 01 Mar 2005 Posts: 277

Okay, now that you have had time to evaluate the direction you want to take with zApp, out of the wish lists here, which ones are your highest priorities?

Also, how hard would it be for you to add minimize to system tray (with menu)? If this was added there was an application I would want to rewrite in zApp (from VB.)

Posted: Sat Aug 06, 2005 1:14 am

Minimize to system tray? Can't you already do that in zApp? Look in the system menu in the upper-left corner. Seems like there was a system tray option in there. If not, it's built into the ThemeEngine stuff, so it should be trivial to add. I can certainly make this a priority if it's not yet working. As far as getting a button for minimize-to-tray into the main caption bar of the window, that depends upon the theme. Play with some of the themes...I think a couple of them have a minimize-to-tray button in them. But it's up to the theme to add that button since I can't just add my own button with my own bitmap that might look horrible depending upon the theme you are using.

Anyway, back to priorities...Highest current priorities:

1) Get new copy protection working with zApp. Will be using Armadillo, and haven't yet decided whether to use RegNow or to go back to using my own shopping cart. I already have a merchant account, and I'm leaning towards doing it myself and avoiding all of the overhead charges of an ecommerce provider. After all, the only reason I stopped doing ecommerce myself 5 years ago was because I was forced to use the ViaTech ecommerce in order to use their eLicense copy protection. Without eLicense, I can go back to my own ecommerce. Just have to get it all working in PHP (was originally written in ASP). Not a zApp issue per say, but I want to use zApp as a test case for this before I rewrap zMUD with Armadillo.

2) A basic IDE. I will take zAppPro and add the ability to edit the ZML file, both in the tree view and in a source-dump window. Just something basic to give zApp a "face". The Encrypt and Link options will popup a dialog prompting an upgrade to zAppPro if zAppPro isn't licensed. This changes the license check for zAppPro...it will no longer be done when you first try to open the IDE...it will only be done when you try to use an IDE Pro feature.

3) Sprite system. Or, more generally, a DirectX component. I need to investigate DirectX components for a new MUD client. Whether this is the same as the sprite system, or something else is unknown. I'm still looking at the TurboSprite system, but with only 16-bit color support I'm not sure if it's good enough. I'd also like something that already supported PNG sprites. But this might be something I can add myself. I've sent the TurboSprite author an email with questions, but haven't heard back yet (which isn't a good sign support-wise).

4) A Canvas component would fit in with (2) as well and will probably be done at the same time.

5) If I pick TurboSprite for the graphics system, then I'll probably also pick TurboSound for the sound engine. Again, I need something for the new MUD client to better support MSP, so sound is a higher priority now.

6) Basically, my priorities switch from "email-things" to "MUD-client-things". In porting zMUD into zApp I'm sure I'll come across all sorts of little things that need to be fixed or added in zApp. But DirectX graphics and Sound support at the main things I'll need that zApp doesn't have yet.

Since a new MUD client looks like the best way to generate some much needed money right away, you'll see a big focus on this. zApp will benefit along the way. But I probably won't take the time to work on the "MegaDemo" right now, or anything that is too geeky in zApp that isn't needed in zMUD.

What made me change my plans on this (a new MUD client vs eMobius) is that even once eMobius is at a public release stage, it will still take time for it to build sales in a brand new market. So, 2-3 months for a beta version, another 3-4 months to get it to public status, then another several months to start building up sales. That's a year before new money comes in. I'm no longer sure I can last that long.

On the other hand, a new MUD client caters to my existing customers. The zMUD code base already exists, so I'm not starting from scratch. Writing the MUD client using zApp provides a whole new range of possibilities that should blow-away many zMUD users. This makes it something compelling for people to upgrade/buy. If it takes 2 months to make a new MUD client in zApp that is compatible with zMUD, I can start getting new money for it right away. In fact, I'd expect a lot of people to buy it within the first month. And the existing zMUD customer base is large enough that this could be a significant boost to business. It would also boost zApp sales, since the plugins for the MUD client would use zApp. It would also increase the value of zMUD so that the MUD icon advertising in February would still bring in a good chunk of sales. So, by March, this should put Zugg Software in a *much* better financial situation. At that point I'd be better able to write a quality email client, rather than rushing something now.

Yeah, I know, it seems like I'm switching strategy and directions every few weeks. Well, sometimes it takes a while to really think stuff through completely. Maybe eMobius was just a necessary step in order to get me to make zApp, so I could then make a newer and better MUD client.

Adept Joined: 01 Mar 2005 Posts: 277

With regard to minimize to system tray I was hoping to be able to do that through code.

All the rest sounds good to me and the change in direction is very logical and necessary. If ZuggSoft doesn't survive either does zApp and I like zApp too much to see it disappear (and obviously, I want to see ZuggSoft successful regardless.)

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

I know this is going to aggrivate you Zugg, and I appologize for that, however:

When did your focus change from e-mail client to porting zMud to zApp? Did I miss something? I personally feel slightly abandoned, being that I was enticed to purchase an 'early adopter' version of eMobius...yet your focus has shifted gears a lot it seems. I understand that you cannot survive on profits from a not yet released e-mail client of the future, but thats what taking risks is for.

I don't know, I'm just dissapointed, I don't mud anymore, I don't have need for another declarative/scripting system, I need a robust e-mail client.

I know that this sounds extremely negative and I'm sure I come off as such due to my infrequent posting, but I follow these boards carefully..and I am a fan of your work, otherwise I wouldn't be here. I'm just looking for something as far as eMobius is concerned. Obviously you can't give a date for a release, or a beta anymore, how about a date when you may start to think about working on it again?

Posted: Sat Aug 06, 2005 12:31 pm

Krule, go read the zMUDXP thread in the zMUD forum and you'll see the thought process about doing a new MUD client using zApp.

And don't worry, early eMobius adopters will get a benefit from this...I always reward early adopters no matter what happens.

I'll start thinking about eMobius again when I feel that Zugg Software is financially stable enough, which will probably be after the new MUD client is released. There is no way for me to estimate any sort of date.

As I have said in the other posts, there is no way I can please everyone. And frankly, my long-time burning desire to try and please everyone is what has led to this problem. And I'd rather catch the problem early now and do something else that will please a greater number of people and keep Zugg Software alive for the long term, than to get stuck in another zMapper situation.

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

Ok, read the thread..(I dont hit up that forum anymore, like I said I stopped mudding a while ago) ... well I mean, if you think this is what will make Zugg Software financially stable enough so you can focus on eMobius, then I guess it's the way to go. I hope your right, and look forward to it's success so you can continue with your original plan.

Otherwise, heck, I may have to start building an eMail client with zApp (Cept then IBM would own it :\)

Wizard Joined: 14 Oct 2000 Posts: 1368

Krule everything you code is owned by IBM? That's crazy. I don't understand how people can agree with contracts like that. Even how companies can get away with writing such contracts is a riddle in itself. Such writings belong to the garbage bin. No wonder free software foundation was created even though I dislike it.

Edit: A funny example is if you enjoy code a lot in your spare time as well as working. This means you technically work a huge overtime, doesn't it? So contracts like these take huge advantage of people. I would even go so far to compare it to slavery. Then again I have pretty strong opinions on poor copyright usage.

Sorry for creating an off topic post. This is a kind of post that attracts my "license-nerve" as some people call it.

Adept Joined: 01 Mar 2005 Posts: 277

Rorso, I was thinking the same thing. That is one crazy contract but it is fairly common.

However, just think how interesting it would be if IBM owned some zApp code... hmmmm....

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

Well, no, not everything I code is owner by IBM. However anything that I program that is in direct competition with IBM is property of IBM. As well as any ideas that I may come up with, any patents or other Intellectual Capital that I think of, that is related to anything that IBM does.

And it makes sense to some degree once you start working there. I have access to SOOOOO much information that it would be incredibly easy for me to use this information to create an incredible powerful application that fit the needs of millions of customers. They can't limit my access to this, as I need it for various functions in my job, therefore they have to have a blanket statement saying that anything you make is their property (if it falls under the umbrella of software they make or may make). It makes sense to me, and thats why I signed the agreement. IT sucks, to some degree, but for what they are paying me at 21 years old, I really have no right to complain, plus any software I make I don't profit from, so it makes little difference to me (For instance I'm in the process of writting an application that would mimic the linux tail-f command for windows, with some filtering and searching, in fact this may be a decent zApp application, yet I'm writing in Java, so if anyone is interested in writing it in zApp we can compare them next week :p).

Wizard Joined: 14 Oct 2000 Posts: 1368

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

Well firstly, I've only just started working there, so any ideas I gave wouldn't really count. Secondly, IBM isn't in the business of creating declarative/scripting languages, so we're ok there, as far as eMobius is concerned, I suppose that I'd have to refrain from doing so.

However you also have to think, Rorso, about whether a company like IBM would actually go after any of my work, or ideas I've assisted with. That would be a lot of bad press. They RARELY put these contracts into effect, only when there is a product that competes directly with one of theirs, that may be gaining market share, and even then, it's tough as hell to prove.