Zugg Software :: View topic

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

You already do layouts with Zmud... how hard would it be to adapt that kind of thing but on a more global scale?

Initially I was thinking how a lot of new applications read XML layout files which allow you to customize everything even the position of buttons, etc...

Ideally, if we could do the XML layouts for ZuggMail that would be the most rox0r thing ever... but realistically the ability to do your own layout with docking would be fine...

The main things would be the ability to attach/detach the menu bar, folder title bar, folders list, email list, and preview pane. Optionally, some people might like the ability to have multiple folders open at the one time eg in a MDI tiled layout.

All I really want is something that mimics outlook express (without all that 'outlook today' crap you get with full outlook) but from a 'begin using zuggmail today with NO learning curve from your old email app' perhaps we could build the whole thing to use XML layouts (for each user)... and these could be included as part of the setup wizard eg: "ZuggMail can be made to look like your old email client, please select one from the list: Eudora, Outlook 97, Outlook 2000, Outlook 2003, Outlook Express, Mozilla, yadda yadda yadda"

Perhaps something for version 2.0 but version 1.0 would need to be built in a modular/extensible fasion so that in 2.0 you could add these 'style sheets'.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

On this same topic, you're going to need to make it multi-lingual in the end too... so you'll be loading strings anyway, it probably isn't too hard to load x, y, width and height at the same time too (and for that matter 'alignment').

Posted: Wed Dec 17, 2003 1:42 pm

well you could detect which the default mailclient is and just "copy" its settings for layout
I think personally I wold go with the idea of designing it to use xml layout definitions from the word go. Essentially converting the ZMud system to this (heh assuming you don't already do it, I haven't looked) is virtually a no brainer, as it is merely a change to the way it is saved/read.
Oh that reminds me, it would be nice to be able to assign graphics of my choice to the buttons on toolbars, and place them wherever I choose - including having an option to float a reply button near the bottom of the page as I view it (dunno, just seems nice to me, I generally like such things at the top of the screen to minimise loss of screen-estate, and floating on the rhs means it is unlikely to cover much text but is where I naturally think to click to reply)

Posted: Wed Dec 17, 2003 11:35 pm

I definitely will NOT be using the same system that I used in zMUD. As you might remember, I tried using the builtin docking support in Delphi 5 only to find that it was horrible and very buggy. I got the Delphi source code and tried to fix it and force it to work, but it still has lots of issues and is one of the parts of zMUD I hate to touch because it breaks so easily.

The idea of doing XML layout files is a really interesting one. I definitely want some method to let the user control the layout. I never gave this much thought when I first designed zMUD and it's another one of those features that needs to be designed in advance before doing much coding. If I can come up with a flexible but robust method for handling layouts, it would be very cool.

Rainchild is correct that making ZuggMail look like your existing email client is *very* important. Of course, most clients emulate Outlook, so that shouldn't be hard. But something more customizable would sure be nice. I'll have to take a look to see if there are any good 3rd party Delphi components that handle layout nicely, otherwise I'll have to write my own.

"Multi-lingual" is a big issue however, and this is something I've decided just not to do a good job on. ZuggMail will NOT be a UNICODE application. Truely supporting UNICODE is very complex and, amoung other things, would require me to upgrade my version of Delphi, which I don't want to do. zMUD is tied to the docking code in Delphi 5 that was removed in Delphi 6. Do upgrading Delphi could break a *lot* of existing code. Also, supporting UNICODE means that the database store for the email is twice as large since it takes 2 bytes for each character instead of one.

So, ZuggMail will NOT be UNICODE. It's a market that I'm totally not interested in. It *WILL* support any single-byte language, such as English, German, French, Russian, Italian, etc, etc. The only people it won't work for are the eastern languages such as Chinese, Japanese, etc.

Posted: Wed Dec 17, 2003 11:47 pm

Btw, another issue that is important is loading speed. What I found when I did the international support for zMUD that allows you to translate all of the strings displayed by the program was that dialog creation became *very* slow. Having to load all of those strings and replace them at dialog creation time was too time consuming. So, I want to having something that gives flexibility, without slowing down the program.

ZuggMail needs to come up VERY FAST. I don't want people calling it "bloatware" like Microsoft stuff. And it's all a matter of first impressions. A completely customizable interface might be cool, but if it tremendously slows down the user interface loading, nobody will like it.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Incidentally C++Builder 5 and 6 will co-exist happily on the same system, but it's pretty easy to accideintally open the version 5 project in version 6 or vice versa which causes a bit of grief. So you probably could run Delphi 5 and 6 together but anyways.

Docking has always been pretty dodgy, but this new XML layout / "skin" files are pretty cool. It's a bit easier with a small app such as winamp (and personally I don't want a skinned email client) but you should be able to apply the principal to an email client pretty easily.

Double-byte characters are a pain, I was thinking more the single byte languages, and the option to specify your own menu design as part of the layout ... so provide "Actions" that you can attach to functions you put on your menu. Eg the "AppExit" or "NewEmail" actions put into a file menu could look like this:

<Menu Name="File">
<MenuEntry Name="New" Action="NewEmail">
<MenuEntry Name="Exit" Action="AppExit">
</Menu>

I guess you might need to put in &'s for the hot key eg E&xit

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Hrm you have a point about speed. I guess we Pentium 4 user's don't care so much because no matter what you throw at it, it's fast... but I could see how testing on a pentium 200 could slow things down significantly... especially when you start accessing databases etc.

Having said that, though, did you try loading all those strings into memory at application startup and put them in a hashed or binary searchable array?

Posted: Thu Dec 18, 2003 12:23 am

Nope, never did that. Again, the Translation feature in zMUD was an addon...it was never designed for that kind of functionality from the beginning.

What I ended up doing was a trick/kludge. I trap Delphi when it loads a form, loop through each element of the form, look for the name of the element in the translation file, and replace the visible text if it is found.

When I switched from IniFile to MemIniFile, things got a bit faster. Adding a hash table would be even better. The problem is that I had to do this for each form, and as I would add new forms, I'd forget to add them. So, a lot of the newer dialogs in zMUD don't use the translation table, for example. Since nobody even sent me even the start of any language translation files, I decided nobody was using the feature in zMUD and stopped worrying about it.

In ZuggMail, I need to design an architecture that works for every form and layout automatically with very little fuss. Then it should be more robust and easier to optimize.

zMUD started doing stuff like the customizeable menu when I added the Global settings file and converted the main zMUD toolbar from a fixed Delphi toolbar into a zMUD toolbar with zMUD buttons. That then allowed you to redefine the toolbar in zMUD, and was cool. So yes, defining the toolbar and menu with an XML file is a good idea. There will also be a user interface within ZuggMail to allow you to customize without having to edit the raw XML file. So, most users probably won't bother with the XML file, but it will be there for people to play with.

Of course, then there is the issue when upgrading ZuggMail. Kind of like the DEFAULT.MUD issue with zMUD. ZuggMail is going to want to distribute updates to the default XML layout file. If you have changed this, then either your changes are overwritten, or you don't get the new settings in the updated file.

Not really sure how to handle this except maybe with a USER.XML file that is loaded after the default file and allows you to replace existing XML entities. Then you just add the changes you want with no fear of messing up the default file.

You are lucky...I'm still programming with a 233Mhz computer. So, if it's fast enough for me, it should be plenty fast for you Smile

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Man, programming on a 233... that's just massochistic! Maybe we all need to pitch in to buy Zugg a new PC for Xmas ;)

Re: DEFAULT.MUD issue -- take the .WIZ initiative you used in Zmud and apply it here. Have layout files called .LAY or something, store the user layouts in the user subdirectory and the global/zuggmail layouts in the main zuggmail directory, then you can just select a new layout file from a dropdown menu. That way you can have zuggmailoutlook.lay or zuggmaileudora.lay etc.

Then you could have zuggmailrainchildmyfunkylayout.lay or if user's aren't getting subdirectories just have zuggmaillayouts and zuggmaillayoutsuser

Other programs do it as a directory rather than a single file, so that they can put bitmaps and icons in their own directory without overwriting other icons... you could simply have a layouts directory with each layout/skin taking its own subdirectory.

zuggmaillayoutsoutlook
zuggmaillayoutseudora
zuggmaillayoutsmyfunkylayout

Posted: Thu Dec 18, 2003 3:03 am

No, this is a bit different than the wizard.

With the wizard, you want to see a list of *all* wizard rules. So it makes sense to search out all of the *.wiz files and list everything you find.

Layout, menus, button bars, etc are different. What if you just want to change the title or icon of an existing button? What if two different layout files change the same button? Who wins?

With the DEFAULT and USER file it's obvious what order they are searched and how you override the defaults.

Plugins *will* be able to add buttons, menus, etc, but will do so via the API and not via some random layout file.

Finally, the whole idea of the "layout" file is to control the "layout" of the program: ie, how the different windows are docked together, etc. You can't put this kind of info into more than one file. There is a single "layout" of the screen. Loading another layout file would replace the current layout with the new one. So, only the last layout file loaded would really matter.

And don't worry about the computer. My nice Athlon 2800 Alienware system is downstairs for game playing. I don't do work on the game machine, and I don't play games on the work machine. But this work machine has a bunch of development tools installed, custom Delphi components, etc. Stuff that I really don't want to spend time reinstalling onto a new computer. And for running Delphi, doing email, surfing the web, etc, this computer is plenty fast.

And it *does* keep me writing efficient code so that Zuggsoft products don't go down the bloatware path of Microsoft software.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I was more thinking that there should be a list of layout files, so that you could select which one you wanted to use from a dropdown or radio group. Eg:

Select Layout To Use:
( ) ZuggMail Standard [zuggstd.lay]
( ) Outlook Express [oexpress.lay]
( ) Outlook 2000 [o2k.lay]
( ) Eudora [eudora.lay]
( ) Rainchild's Layout [rainchildrainchild.lay]

You have one file per layout, and that one file has everything in it from menu defs, window positions, and window behavior (eg open new window or use tabs). These files determine the physical layout of the toolbars, panes, etc. You have a separate file which saves the actual window size and position of the splitter bars etc.

Maybe it's a bit hard to explain in text, but basically I was meaning that each layout has its own file name, rather than saving the 5 'standard' layouts within a default.lay file.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

As an example you might have:

Posted: Sun Jan 04, 2004 11:28 am

I like Rainchild's idea - specifically since it would let me spend time learning to play with xml and create a useful layout, then give it to a friend who might not have the time/patience/desire to learn something new. If it is all within one file, it would make sharing the different layouts a little difficult.

Oh - incidentally, This is kind of related to the layout...kind of...but not worth a string of its own. Every client I've tried annoys me when it first opens up and goes straight to the setup wizard. Cancelling out almost takes more time than setting up using the wizard... so maybe there could be an option like the old winzip's first startup screen - advanced or basic setup? Where advanced takes you straight into the program, while basic launches the wizard. Since you're targeting power users, I think this would be appreciated, and probably smart, since it would make it easier for people to have a quick look at the product and what it offers.

Posted: Mon Jan 05, 2004 8:55 am

In my current client, you can't change the layout as much, but you can specify which "cell" gets which information, so if you had:

XXXXX YYYYYYYY
XXXXX YYYYYYYY
XXXXX YYYYYYYY
XXXXX
XXXXX ZZZZZZZZ
XXXXX ZZZZZZZZ
XXXXX ZZZZZZZZ

You could easily change that to:

ZZZZZ XXXXXXXX
ZZZZZ XXXXXXXX
ZZZZZ XXXXXXXX
ZZZZZ
ZZZZZ YYYYYYYY
ZZZZZ YYYYYYYY
ZZZZZ YYYYYYYY

Or any other varient that you choose. If nothing else, this simple type of rotating would be nice to have, as I know I sometimes like my preview window to be above the message listing. It's just a personal preference, but it should be atleast considered. This could be done with something like Rainchild suggested, however, if nothing else, I'm suggesting that this type of feature be added.

Posted: Mon Jan 05, 2004 10:52 pm

Yes, the flexible XML layout being proposed would certainly handle those cases.

Caleb, please post your comment/suggestion about the initial setup to a separate topic thread. Let's not get these threads too confused.