long time no email from me, it's time to get working again. I started working for Liferay in January, and while there are no definite plans on cooperation etc, I'm happy to say that I started working full-time on UI! Due to the fact that I'm able to spend nearly 8 hours everyday now for UI, I'm progressing quite well:
- There will be no 1.0.1 release. It's a pity we didn't make it in december, but it cannot be undone now. - The absolute code deadline for the 1.1 release will be *January 24th * - please add it to your calendar. After that, there will be exactly one week for testing, documentation and of course bugfixing. - I'll be in Boston from February 1st to February 3rd. During this time, I will roll out a official beta release (that should be pretty stable at this point). We will then allow for 1-2 weeks of public testing, and according to the feedback, set the release to 'stable'. - The component API, as in http://jquery.grouphub.com/W691709 , is now *definite*. It's important to note that there will be no generic activate() method, because it's not specific enough and doesn't fit into the rest of the API. The external function *must* begin with attach, make or become (see document, no $(..).draggable() anymore [if there are many votes against the removal of the simpler syntax, I'm going to consider to allow it as second way]). A script may expose 4 external (external as in $.fn) methods (not less than 3, not more than 4) methods. These are enableNAME, disableNAME, removeNAME and the generic method for everything else: changeNAME. changeNAME always uses two passed arguments, the first is the key, the second the value (i.e change the helper for the current draggable: $(..).changeDraggable('helper', 'clone') ). Please make sure you change everything until the 24th - if you absolutely don't agree with something, you can make a proposal during the coming weekend, but please as soon as possible. Anyway, it should be pretty easy for both the developers and the users. - There will be *no get instance methods anymore* (draggableInstance() for example). People who want to have the full control can instantiate the scripts themselves (i.e. new $.ui.draggable(options))
The next big thing is that we will stop using basecamp from this day on. The reason I decided to move away from basecamp is that it doesn't have any good workflow control (actually none :-) ). We are using Taskado now - it features more workflow control (delegate, states, proofing, writing etc), it's free and much more you'll see for yourself (the UI is a little clumsy but I can live with it). Please use it as much as possible and actively add / take tasts. It's important that we get it rolling.
There are a couple of critical management steps I need to do in order to get out quality releases with everyone participating:
- *This will be the last UI/FX specific management email to this list*. This will force everybody to use Taskado (yes, I'm not pleased with the [missing] communication the last weeks). All further messages will be posted to Taskado (it even allows to comment and track history for each task). - Only developers of a plugin actually officially released with jQuery UI are invited to use Taskado. The exceptions are John Resig, Karl Swedberg and Rey Bango at the time being. This is not meant to kick people out of the project, but to better be able to track the progress / keep it clean. It absolutely does not mean you should throw away your current plugins in experimental/ of course. This mailing list is still the right place to discuss about a possible inclusion. If you have a plugin, that you think is stable and worth being added, post it to the mailing list and let everybody comment it and use it. - I did not forget about designers / skinning. Please give me some days to create specific categories before I'll invite the people concerned. - Also, I did not forget about the uploader plugin by Gilles and the toolbar plugin by Miksago, both proposed for addition. I will review them as promised early next week and come back to you to discuss what needs to be done as a next step. - *The experimental folder will be removed*. Please move all your experimental scripts to either a) your branches (ask John if you should need one), or b) the general plugins directory. I'll also talk to John about a general 'alpha' folder, directly under trunk/alpha, or something like that. I'll keep you updated.
Thanks so far, I'm very optimistic that 1.1 will be a great release! Hope everyone had great holidays and a happy new year.
> long time no email from me, it's time to get working again. I started > working for Liferay in January, and while there are no definite plans on > cooperation etc, I'm happy to say that I started working full-time on UI! > Due to the fact that I'm able to spend nearly 8 hours everyday now for UI, > I'm progressing quite well:
> - There will be no 1.0.1 release. It's a pity we didn't make it in > december, but it cannot be undone now. > - The absolute code deadline for the 1.1 release will be *January > 24th* - please add it to your calendar. After that, there will be > exactly one week for testing, documentation and of course bugfixing. > - I'll be in Boston from February 1st to February 3rd. During this > time, I will roll out a official beta release (that should be pretty stable > at this point). We will then allow for 1-2 weeks of public testing, and > according to the feedback, set the release to 'stable'. > - The component API, as in http://jquery.grouphub.com/W691709 , is > now *definite*. It's important to note that there will be no generic > activate() method, because it's not specific enough and doesn't fit into the > rest of the API. > The external function *must* begin with attach, make or become (see > document, no $(..).draggable() anymore [if there are many votes against the > removal of the simpler syntax, I'm going to consider to allow it as second > way]). > A script may expose 4 external (external as in $.fn) methods (not > less than 3, not more than 4) methods. These are enableNAME, disableNAME, > removeNAME and the generic method for everything else: changeNAME. > changeNAME always uses two passed arguments, the first is the key, the > second the value ( i.e change the helper for the current draggable: > $(..).changeDraggable('helper', 'clone') ). > Please make sure you change everything until the 24th - if you > absolutely don't agree with something, you can make a proposal during the > coming weekend, but please as soon as possible. Anyway, it should be pretty > easy for both the developers and the users. > - There will be *no get instance methods anymore*(draggableInstance() for example). People who want to have the full control > can instantiate the scripts themselves (i.e. new > $.ui.draggable(options))
> The next big thing is that we will stop using basecamp from this day on. > The reason I decided to move away from basecamp is that it doesn't have any > good workflow control (actually none :-) ). We are using Taskado now - it > features more workflow control (delegate, states, proofing, writing etc), > it's free and much more you'll see for yourself (the UI is a little clumsy > but I can live with it). Please use it as much as possible and actively add > / take tasts. It's important that we get it rolling.
> There are a couple of critical management steps I need to do in order to > get out quality releases with everyone participating:
> - *This will be the last UI/FX specific management email to this > list* . This will force everybody to use Taskado (yes, I'm not > pleased with the [missing] communication the last weeks). All further > messages will be posted to Taskado (it even allows to comment and track > history for each task). > - Only developers of a plugin actually officially released with > jQuery UI are invited to use Taskado. The exceptions are John Resig, Karl > Swedberg and Rey Bango at the time being. This is not meant to kick people > out of the project, but to better be able to track the progress / keep it > clean. It absolutely does not mean you should throw away your current > plugins in experimental/ of course. This mailing list is still the right > place to discuss about a possible inclusion. If you have a plugin, that you > think is stable and worth being added, post it to the mailing list and let > everybody comment it and use it. > - I did not forget about designers / skinning. Please give me some > days to create specific categories before I'll invite the people concerned. > - Also, I did not forget about the uploader plugin by Gilles and the > toolbar plugin by Miksago, both proposed for addition. I will review them as > promised early next week and come back to you to discuss what needs to be > done as a next step. > - *The experimental folder will be removed*. Please move all your > experimental scripts to either a) your branches (ask John if you should need > one), or b) the general plugins directory. I'll also talk to John about a > general 'alpha' folder, directly under trunk/alpha, or something like that. > I'll keep you updated.
> Thanks so far, I'm very optimistic that 1.1 will be a great release! Hope > everyone had great holidays and a happy new year.
> long time no email from me, it's time to get working again. I started > working for Liferay in January, and while there are no definite plans on > cooperation etc, I'm happy to say that I started working full-time on UI! > Due to the fact that I'm able to spend nearly 8 hours everyday now for UI, > I'm progressing quite well:
> - There will be no 1.0.1 release. It's a pity we didn't make it in > december, but it cannot be undone now. > - The absolute code deadline for the 1.1 release will be *January > 24th* - please add it to your calendar. After that, there will be > exactly one week for testing, documentation and of course bugfixing. > - I'll be in Boston from February 1st to February 3rd. During this > time, I will roll out a official beta release (that should be pretty stable > at this point). We will then allow for 1-2 weeks of public testing, and > according to the feedback, set the release to 'stable'. > - The component API, as in http://jquery.grouphub.com/W691709 , is > now *definite*. It's important to note that there will be no generic > activate() method, because it's not specific enough and doesn't fit into the > rest of the API. > The external function *must* begin with attach, make or become (see > document, no $(..).draggable() anymore [if there are many votes against the > removal of the simpler syntax, I'm going to consider to allow it as second > way]). > A script may expose 4 external (external as in $.fn) methods (not > less than 3, not more than 4) methods. These are enableNAME, disableNAME, > removeNAME and the generic method for everything else: changeNAME. > changeNAME always uses two passed arguments, the first is the key, the > second the value ( i.e change the helper for the current draggable: > $(..).changeDraggable('helper', 'clone') ). > Please make sure you change everything until the 24th - if you > absolutely don't agree with something, you can make a proposal during the > coming weekend, but please as soon as possible. Anyway, it should be pretty > easy for both the developers and the users. > - There will be *no get instance methods anymore*(draggableInstance() for example). People who want to have the full control > can instantiate the scripts themselves (i.e. new > $.ui.draggable(options))
> The next big thing is that we will stop using basecamp from this day on. > The reason I decided to move away from basecamp is that it doesn't have any > good workflow control (actually none :-) ). We are using Taskado now - it > features more workflow control (delegate, states, proofing, writing etc), > it's free and much more you'll see for yourself (the UI is a little clumsy > but I can live with it). Please use it as much as possible and actively add > / take tasts. It's important that we get it rolling.
> There are a couple of critical management steps I need to do in order to > get out quality releases with everyone participating:
> - *This will be the last UI/FX specific management email to this > list* . This will force everybody to use Taskado (yes, I'm not > pleased with the [missing] communication the last weeks). All further > messages will be posted to Taskado (it even allows to comment and track > history for each task). > - Only developers of a plugin actually officially released with > jQuery UI are invited to use Taskado. The exceptions are John Resig, Karl > Swedberg and Rey Bango at the time being. This is not meant to kick people > out of the project, but to better be able to track the progress / keep it > clean. It absolutely does not mean you should throw away your current > plugins in experimental/ of course. This mailing list is still the right > place to discuss about a possible inclusion. If you have a plugin, that you > think is stable and worth being added, post it to the mailing list and let > everybody comment it and use it. > - I did not forget about designers / skinning. Please give me some > days to create specific categories before I'll invite the people concerned. > - Also, I did not forget about the uploader plugin by Gilles and the > toolbar plugin by Miksago, both proposed for addition. I will review them as > promised early next week and come back to you to discuss what needs to be > done as a next step. > - *The experimental folder will be removed*. Please move all your > experimental scripts to either a) your branches (ask John if you should need > one), or b) the general plugins directory. I'll also talk to John about a > general 'alpha' folder, directly under trunk/alpha, or something like that. > I'll keep you updated.
> Thanks so far, I'm very optimistic that 1.1 will be a great release! Hope > everyone had great holidays and a happy new year.
> 2008/1/10, Paul Bakaus <paul.bak...@googlemail.com>:
> > Hi folks,
> > long time no email from me, it's time to get working again. I started > > working for Liferay in January, and while there are no definite plans on > > cooperation etc, I'm happy to say that I started working full-time on UI! > > Due to the fact that I'm able to spend nearly 8 hours everyday now for UI, > > I'm progressing quite well:
> > - There will be no 1.0.1 release. It's a pity we didn't make it in > > december, but it cannot be undone now. > > - The absolute code deadline for the 1.1 release will be *January > > 24th* - please add it to your calendar. After that, there will be > > exactly one week for testing, documentation and of course bugfixing. > > - I'll be in Boston from February 1st to February 3rd. During this > > time, I will roll out a official beta release (that should be pretty stable > > at this point). We will then allow for 1-2 weeks of public testing, and > > according to the feedback, set the release to 'stable'. > > - The component API, as in http://jquery.grouphub.com/W691709 , is > > now *definite*. It's important to note that there will be no > > generic activate() method, because it's not specific enough and doesn't fit > > into the rest of the API. > > The external function *must* begin with attach, make or become > > (see document, no $(..).draggable() anymore [if there are many votes against > > the removal of the simpler syntax, I'm going to consider to allow it as > > second way]). > > A script may expose 4 external (external as in $.fn) methods (not > > less than 3, not more than 4) methods. These are enableNAME, disableNAME, > > removeNAME and the generic method for everything else: changeNAME. > > changeNAME always uses two passed arguments, the first is the key, the > > second the value ( i.e change the helper for the current > > draggable: $(..).changeDraggable('helper', 'clone') ). > > Please make sure you change everything until the 24th - if you > > absolutely don't agree with something, you can make a proposal during the > > coming weekend, but please as soon as possible. Anyway, it should be pretty > > easy for both the developers and the users. > > - There will be *no get instance methods anymore*(draggableInstance() for example). People who want to have the full control > > can instantiate the scripts themselves (i.e. new > > $.ui.draggable(options))
> > The next big thing is that we will stop using basecamp from this day on. > > The reason I decided to move away from basecamp is that it doesn't have any > > good workflow control (actually none :-) ). We are using Taskado now - it > > features more workflow control (delegate, states, proofing, writing etc), > > it's free and much more you'll see for yourself (the UI is a little clumsy > > but I can live with it). Please use it as much as possible and actively add > > / take tasts. It's important that we get it rolling.
> > There are a couple of critical management steps I need to do in order to > > get out quality releases with everyone participating:
> > - *This will be the last UI/FX specific management email to this > > list* . This will force everybody to use Taskado (yes, I'm not > > pleased with the [missing] communication the last weeks). All further > > messages will be posted to Taskado (it even allows to comment and track > > history for each task). > > - Only developers of a plugin actually officially released with > > jQuery UI are invited to use Taskado. The exceptions are John Resig, Karl > > Swedberg and Rey Bango at the time being. This is not meant to kick people > > out of the project, but to better be able to track the progress / keep it > > clean. It absolutely does not mean you should throw away your current > > plugins in experimental/ of course. This mailing list is still the right > > place to discuss about a possible inclusion. If you have a plugin, that you > > think is stable and worth being added, post it to the mailing list and let > > everybody comment it and use it. > > - I did not forget about designers / skinning. Please give me some > > days to create specific categories before I'll invite the people concerned. > > - Also, I did not forget about the uploader plugin by Gilles and > > the toolbar plugin by Miksago, both proposed for addition. I will review > > them as promised early next week and come back to you to discuss what needs > > to be done as a next step. > > - *The experimental folder will be removed*. Please move all your > > experimental scripts to either a) your branches (ask John if you should need > > one), or b) the general plugins directory. I'll also talk to John about a > > general 'alpha' folder, directly under trunk/alpha, or something like that. > > I'll keep you updated.
> > Thanks so far, I'm very optimistic that 1.1 will be a great release! > > Hope everyone had great holidays and a happy new year.
> Hi folks,
> - Also, I did not forget about the uploader plugin by Gilles and the
> toolbar plugin by Miksago, both proposed for addition. I will review them as
> promised early next week and come back to you to discuss what needs to be
> done as a next step.
I'm happy to hear about the organization focus, and wanted to mention something may already be a part of Pauls API, Of course I realize your 24th goal is ambitious so what I'm mentioning here is not meant to add any pressure to that.
In general the 'view' pattern I work with uses a ViewFactory to in some way get the required data and append dom (eg xhtml/styles) . The ViewFactory is responsible for, among other things, the two methods 'attach' and 'detach' which create and destroy the dom I just mentioned. The View, however, is responsible for the same two methods, 'attach/detach', but the 'attach' in this case is responsible for attaching plugins and 'detach' is responsible for removing any dom artifacts added by those plugins.
The View detach method, so far, is not a very nice or clean process and I often seem unable to reliably detach dom artifacts created by plugins. It would be wonderful from my perspective if every ui plugin where required to provide a 'detach' method to clean up any artifacts it creates. I haven't been able to update for a few weeks but the dialog doesn't seem to provide a clean way to detach the plugin generated artifacts (not to pick on it because I like/use it often).
The major problem is that as plugins feel free to create more and more dom artifacts, they rarely clean them up well, primarily because most apps refresh via a request/response cycle eventually. If you are willing to presuppose that some apps will run without 'ever' having a request response cycle, these artifacts add up over time and reduce the efficiency of the selector module among other things.
So in summary, assuming I'm responsible for the factory 'attach/ detach' methods to manage the basic dom, it would be nice if all ui plugins were required to implement 'attach(mentioned in Pauls original post)/detach' to manage the additional dom artifacts the plugins creates. It should at least provide a measurable unit test for each plugin.
Thanks, Chris Thatcher (cell) 202 340 9685 christopher.thatc...@comcast.net c...@loc.gov
> long time no email from me, it's time to get working again. I > started working for Liferay in January, and while there are no > definite plans on cooperation etc, I'm happy to say that I started > working full-time on UI! Due to the fact that I'm able to spend > nearly 8 hours everyday now for UI, I'm progressing quite well:
> There will be no 1.0.1 release. It's a pity we didn't make it in > december, but it cannot be undone now. > The absolute code deadline for the 1.1 release will be January 24th > - please add it to your calendar. After that, there will be exactly > one week for testing, documentation and of course bugfixing. > I'll be in Boston from February 1st to February 3rd. During this > time, I will roll out a official beta release (that should be > pretty stable at this point). We will then allow for 1-2 weeks of > public testing, and according to the feedback, set the release to > 'stable'. > The component API, as in http://jquery.grouphub.com/W691709 , is > now definite. It's important to note that there will be no generic > activate() method, because it's not specific enough and doesn't fit > into the rest of the API. > The external function must begin with attach, make or become (see > document, no $(..).draggable() anymore [if there are many votes > against the removal of the simpler syntax, I'm going to consider to > allow it as second way]). > A script may expose 4 external (external as in $.fn) methods (not > less than 3, not more than 4) methods. These are enableNAME, > disableNAME, removeNAME and the generic method for everything else: > changeNAME. changeNAME always uses two passed arguments, the first > is the key, the second the value ( i.e change the helper for the > current draggable: $(..).changeDraggable('helper', 'clone') ). > Please make sure you change everything until the 24th - if you > absolutely don't agree with something, you can make a proposal > during the coming weekend, but please as soon as possible. Anyway, > it should be pretty easy for both the developers and the users. > There will be no get instance methods anymore (draggableInstance() > for example). People who want to have the full control can > instantiate the scripts themselves (i.e. new $.ui.draggable(options)) > The next big thing is that we will stop using basecamp from this > day on. The reason I decided to move away from basecamp is that it > doesn't have any good workflow control (actually none :-) ). We > are using Taskado now - it features more workflow control > (delegate, states, proofing, writing etc), it's free and much more > you'll see for yourself (the UI is a little clumsy but I can live > with it). Please use it as much as possible and actively add / take > tasts. It's important that we get it rolling.
> There are a couple of critical management steps I need to do in > order to get out quality releases with everyone participating:
> This will be the last UI/FX specific management email to this > list . This will force everybody to use Taskado (yes, I'm not > pleased with the [missing] communication the last weeks). All > further messages will be posted to Taskado (it even allows to > comment and track history for each task). > Only developers of a plugin actually officially released with > jQuery UI are invited to use Taskado. The exceptions are John > Resig, Karl Swedberg and Rey Bango at the time being. This is not > meant to kick people out of the project, but to better be able to > track the progress / keep it clean. It absolutely does not mean you > should throw away your current plugins in experimental/ of course. > This mailing list is still the right place to discuss about a > possible inclusion. If you have a plugin, that you think is stable > and worth being added, post it to the mailing list and let > everybody comment it and use it. > I did not forget about designers / skinning. Please give me some > days to create specific categories before I'll invite the people > concerned. > Also, I did not forget about the uploader plugin by Gilles and the > toolbar plugin by Miksago, both proposed for addition. I will > review them as promised early next week and come back to you to > discuss what needs to be done as a next step. > The experimental folder will be removed. Please move all your > experimental scripts to either a) your branches (ask John if you > should need one), or b) the general plugins directory. I'll also > talk to John about a general 'alpha' folder, directly under trunk/ > alpha, or something like that. I'll keep you updated. > Thanks so far, I'm very optimistic that 1.1 will be a great > release! Hope everyone had great holidays and a happy new year.
> I'm happy to hear about the organization focus, and wanted to mention > something may already be a part of Pauls API, Of course I realize your 24th > goal is ambitious so what I'm mentioning here is not meant to add any > pressure to that. > In general the 'view' pattern I work with uses a ViewFactory to in some > way get the required data and append dom (eg xhtml/styles) . The > ViewFactory is responsible for, among other things, the two methods 'attach' > and 'detach' which create and destroy the dom I just mentioned. The View, > however, is responsible for the same two methods, 'attach/detach', but the > 'attach' in this case is responsible for attaching plugins and 'detach' is > responsible for removing any dom artifacts added by those plugins.
> The View detach method, so far, is not a very nice or clean process and I > often seem unable to reliably detach dom artifacts created by plugins. It > would be wonderful from my perspective if every ui plugin where required to > provide a 'detach' method to clean up any artifacts it creates. I haven't > been able to update for a few weeks but the dialog doesn't seem to provide a > clean way to detach the plugin generated artifacts (not to pick on it > because I like/use it often).
> The major problem is that as plugins feel free to create more and more dom > artifacts, they rarely clean them up well, primarily because most apps > refresh via a request/response cycle eventually. If you are willing to > presuppose that some apps will run without 'ever' having a request response > cycle, these artifacts add up over time and reduce the efficiency of the > selector module among other things.
> So in summary, assuming I'm responsible for the factory 'attach/detach' > methods to manage the basic dom, it would be nice if all ui plugins were > required to implement 'attach(mentioned in Pauls original post)/detach' to > manage the additional dom artifacts the plugins creates. It should at least > provide a measurable unit test for each plugin.
> long time no email from me, it's time to get working again. I started > working for Liferay in January, and while there are no definite plans on > cooperation etc, I'm happy to say that I started working full-time on UI! > Due to the fact that I'm able to spend nearly 8 hours everyday now for UI, > I'm progressing quite well:
> - There will be no 1.0.1 release. It's a pity we didn't make it in > december, but it cannot be undone now. > - The absolute code deadline for the 1.1 release will be *January > 24th* - please add it to your calendar. After that, there will be > exactly one week for testing, documentation and of course bugfixing. > - I'll be in Boston from February 1st to February 3rd. During this > time, I will roll out a official beta release (that should be pretty stable > at this point). We will then allow for 1-2 weeks of public testing, and > according to the feedback, set the release to 'stable'. > - The component API, as in http://jquery.grouphub.com/W691709 , is > now *definite*. It's important to note that there will be no generic > activate() method, because it's not specific enough and doesn't fit into the > rest of the API. > The external function *must* begin with attach, make or become (see > document, no $(..).draggable() anymore [if there are many votes against the > removal of the simpler syntax, I'm going to consider to allow it as second > way]). > A script may expose 4 external (external as in $.fn) methods (not > less than 3, not more than 4) methods. These are enableNAME, disableNAME, > removeNAME and the generic method for everything else: changeNAME. > changeNAME always uses two passed arguments, the first is the key, the > second the value ( i.e change the helper for the current draggable: > $(..).changeDraggable('helper', 'clone') ). > Please make sure you change everything until the 24th - if you > absolutely don't agree with something, you can make a proposal during the > coming weekend, but please as soon as possible. Anyway, it should be pretty > easy for both the developers and the users. > - There will be *no get instance methods anymore*(draggableInstance() for example). People who want to have the full control > can instantiate the scripts themselves (i.e. new > $.ui.draggable(options))
> The next big thing is that we will stop using basecamp from this day on. > The reason I decided to move away from basecamp is that it doesn't have any > good workflow control (actually none :-) ). We are using Taskado now - it > features more workflow control (delegate, states, proofing, writing etc), > it's free and much more you'll see for yourself (the UI is a little clumsy > but I can live with it). Please use it as much as possible and actively add > / take tasts. It's important that we get it rolling.
> There are a couple of critical management steps I need to do in order to > get out quality releases with everyone participating:
> - *This will be the last UI/FX specific management email to this > list* . This will force everybody to use Taskado (yes, I'm not > pleased with the [missing] communication the last weeks). All further > messages will be posted to Taskado (it even allows to comment and track > history for each task). > - Only developers of a plugin actually officially released with > jQuery UI are invited to use Taskado. The exceptions are John Resig, Karl > Swedberg and Rey Bango at the time being. This is not meant to kick people > out of the project, but to better be able to track the progress / keep it > clean. It absolutely does not mean you should throw away your current > plugins in experimental/ of course. This mailing list is still the right > place to discuss about a possible inclusion. If you have a plugin, that you > think is stable and worth being added, post it to the mailing list and let > everybody comment it and use it. > - I did not forget about designers / skinning. Please give me some > days to create specific categories before I'll invite the people concerned. > - Also, I did not forget about the uploader plugin by Gilles and the > toolbar plugin by Miksago, both proposed for addition. I will review them as > promised early next week and come back to you to discuss what needs to be > done as a next step. > - *The experimental folder will be removed*. Please move all your > experimental scripts to either a) your branches (ask John if you should need > one), or b) the general plugins directory. I'll also talk to John about a > general 'alpha' folder, directly under trunk/alpha, or something like that. > I'll keep you updated.
> Thanks so far, I'm very optimistic that 1.1 will be a great release! Hope > everyone had great holidays and a happy new year.
