>I have three suggestions:
Sorry for the delay, I'm still not familar with this Mailing list stuff=
>1. The main idea for discussion is this - all of the Syn settings to be
>stored in text files in user friendly view. Advantages:
> * Easy backup outside of Syn
> * Easy access and editing outside from Syn
> * File compare, version control, printing and all other advantages of
> * Editing from Syn in text form - very useful sometimes
> * EASY SHARING with other users (see suggestion 3) - they can be=
>to Syn server and downloaded from other Syn users; mailed on request, ...
I've sometimes thought about this, I'm not a real Registry fan, but this=
was the easiest for the beginning. In general, I think it's a great idea,=
and we should do it, but it would require much coding.
>As far I can see, settings can be grouped in 4 groups (which are stored in
>different files and folders):
I agree completely, just go on.
>2. Second my suggestion is for directory structure. The idea is
>that is specific for the user to be separated from information, that is
>common for all users or even comes with Syn distribution. This can be
>also if Syn is placed on a network server (and common information is
>shared), but the user information is in local folders.
GOOD Point, I like the idea! I think this program became quite complex,=
which makes it uneasy in use. There are to much options to setup, it=
should really come with an environment to work with.
>3. One of the main advantage of this changes will be this - users can easy
>exchange user settings. So if one create good AutoComplete file for given
>language or good set of tools, all other users can use those files without
>recreating them. I think that one development environment (what Syn actual
>is) is nothing without wide community support. So I suggest to be created
>"syn-resources" maillist, where everybody can post resources he create or
>extend, and everybody can receive resources from others. And some person
>collect this resources and put best of them on Syn web site and in next=
>distribution. We can even add "Publish" buttons to settings dialogs to=
>this exchange even easier.
Some users asked me, if it isn't possible to take the settings from home to=
work, e.g. on a Disk, and I had to say no (just the export registry=
settings, which is actually just a workaround). This would satisfy this=
>I have create a small demo. It is based on the latest CVS sources (I=
>and is IFDEF-ed with SYN_EXPORT. It adds "Export" buttons to the "Options"
>and "Project options" dialogs, which allows you to export editor settings
>and project to suggested new format. Some comments about created=
One question, how should we exchange the sources? I think you should check=
then in, there shouldn't be any problems with the current stability, when=
it's proper IFDEF'ed.
Or do you have an other suggestion?
>$[ExportedSettingsPath]\Profiles\Default - here are stored those of editor
>settings, that I think should go in project profile
>$[ExportedProfilePath]\Profile - here are stored those of project=
>that I think should go in project profile. All different project profiles
>must be in $[ExportedSettingsPath]\Profiles subfolders, and the projects
>will contain only link to them.
>*.ACT - here are exported tools and scripts - generally any info about all
>user created menu items and actions should be here. These files can be=
>shared between users - they represent ready tools libraries.
>*.RUN - here are exported run profiles - every profile in separate file.
>These also can be easy shared between users.
>*.TREE - here are exported custom menus and toolbars. Every .TREE file is
>linked to .ACT file, where is stored detailed information about every menu
>or toolbar item in the custom menu. .TREE file contains info only from
>items and in what order is created menu. .ACT and .TREE files will allow=
>to have custom menus, toolbars and popup menus. I have ready code for this
>and can post it to the maillist.
>EVENTS.INI - here are stored events in a separate file. It also can easy=
>shared. Events can be extended to execute not only scripts, but also=
>Other files are described in first suggestion. All the file, folder,
>and key names, file extensions and so are sample and can be discussed.
>I'm waiting for your comments,
This sounds gread, I love this ideas!