From: Louis-Philippe H. <lph...@dr...> - 2008-09-24 13:57:01
|
Hello, Emerging from a discussion on IRC, I would reccommend we make all the default setting changes on trunk as soon as possible so we can fully test them before the release (still a few months out, which is good). We can expect trunk to become little unstable for a while, but many new developments need to be tested throughoutly. * Themes Default theme should be made to one of the litecss-based themes, which is supposed to be our future. Also, I am still waiting for Patrick's design to become more than a poster on a wall. ;) * PDO & Date At this time, a special flag has to be added in local.php to enable it. I think both should be made default if available, with fallback on PEAR::Date and AdoDB if not available. Rather than having a default setting to enable them, we should have a setting to disable them. The difference on the memory footprint is significant and everyone should benefit from it. * Anything else? Just propose you changes to default settings. Now is the right time to do it. Last minute changes during the release process are always bad surprises. -- LP |
From: Stephane C. <se...@lo...> - 2008-09-24 14:30:11
|
Le Wed, Sep 24, 2008 at 09:56:59AM -0400, Louis-Philippe Huberdeau écrivait : > Hello, > > Emerging from a discussion on IRC, I would reccommend we make all the default > setting changes on trunk as soon as possible so we can fully test them before > the release (still a few months out, which is good). > > We can expect trunk to become little unstable for a while, but many new > developments need to be tested throughoutly. > > * Themes > > Default theme should be made to one of the litecss-based themes, which is > supposed to be our future. +1 We need to fix cssmenu... I have some changes pending, but again not time before next week to clean them... > Also, I am still waiting for Patrick's design to become more than a poster on > a wall. ;) > > * PDO & Date > > At this time, a special flag has to be added in local.php to enable it. I > think both should be made default if available, with fallback on PEAR::Date > and AdoDB if not available. Rather than having a default setting to enable > them, we should have a setting to disable them. The difference on the memory > footprint is significant and everyone should benefit from it. For PDO we need to take care of Concat... Categories admin page is not working du to that, But have don't have time now for that. We need more testing, I didn't have any feed back. > * Anything else? Magic ? Don't know if it works, or if it is complete. And I might look dense but, we need to take some decision about PHP5 only stuff and about MySQL 5+ compatibility. >From different discussions it seems parts of TikiWiki assume we have MySQL5+ only... So either we fix these area, or we assume openly that TikiWiki requires MySQL5+ and we dump AdoDB and we implement some major performance optimizations... A+ -- Cordialement -- Stéphane Casset LOGIDÉE sàrl Se faire plaisir d'apprendre 1a, rue Pasteur Tel : +33 388 23 69 77 ca...@lo... F-67540 OSTWALD Fax : +33 388 23 69 77 http://logidee.com |
From: Louis-Philippe H. <lph...@dr...> - 2008-09-24 14:41:52
|
On September 24, 2008 10:10:52 Stephane Casset wrote: > > * PDO & Date > > > > At this time, a special flag has to be added in local.php to enable it. I > > think both should be made default if available, with fallback on > > PEAR::Date and AdoDB if not available. Rather than having a default > > setting to enable them, we should have a setting to disable them. The > > difference on the memory footprint is significant and everyone should > > benefit from it. > > For PDO we need to take care of Concat... Categories admin page is not > working du to that, But have don't have time now for that. > We need more testing, I didn't have any feed back. Can you explain a little more? I did try PDO early on and it seemed to work, but since I create fresh installs often, I forgot to enable it for a while. Now it seems broken. This is exactly why we need it as a default. > > > * Anything else? > > Magic ? Don't know if it works, or if it is complete. Already there by default. Still some work in progress I guess. I will let Marc comment on this as I havn't followed the development so much. Obviously, we would need to start killing the old panels for people to use magic more. > > And I might look dense but, we need to take some decision about PHP5 > only stuff and about MySQL 5+ compatibility. > > From different discussions it seems parts of TikiWiki assume we have > MySQL5+ only... > > So either we fix these area, or we assume openly that TikiWiki requires > MySQL5+ and we dump AdoDB and we implement some major performance > optimizations... I think we should support the supported versions. MySQL still supports 4.1. I think most of tiki runs fine under 4.1 as it supports subqueries, which is the major thing that starts popping up all over the code. (I am fully aware that I started using them and broke 4.0 compatibility). -- LP > > A+ > -- > Cordialement |
From: Marc L. <ma...@ma...> - 2008-09-24 15:47:41
|
Hi! Magic is on by default, but it's not yet to the point of making the old admin panel obsolete. We need a setting that shows & hides the top admin bar. http://dev.tikiwiki.org/magic Can anyone step up for this? Thanks! M ;-) >> >> Magic ? Don't know if it works, or if it is complete. > > Already there by default. Still some work in progress I guess. I will let Marc > comment on this as I havn't followed the development so much. Obviously, we > would need to start killing the old panels for people to use magic more. > >> |
From: Rick S. <ric...@ch...> - 2008-09-24 14:31:02
|
How about site language? For a new install, the default site language is not initially set. I suggest using EN, unless the user specified a specific language from the installation URL (tiki-install.php?lang=XX). -R --- Greetings from Sanford, NC, USA! ----- Original Message ----- From: "Louis-Philippe Huberdeau" <lph...@dr...> To: "Tikiwiki developers" <tik...@li...> Sent: Wednesday, September 24, 2008 9:56 AM Subject: [Tikiwiki-devel] Default changes for 3.x > Hello, > > Emerging from a discussion on IRC, I would reccommend we make all the > default > setting changes on trunk as soon as possible so we can fully test them > before > the release (still a few months out, which is good). > > We can expect trunk to become little unstable for a while, but many new > developments need to be tested throughoutly. > > * Themes > > Default theme should be made to one of the litecss-based themes, which is > supposed to be our future. > > Also, I am still waiting for Patrick's design to become more than a poster > on > a wall. ;) > > * PDO & Date > > At this time, a special flag has to be added in local.php to enable it. I > think both should be made default if available, with fallback on > PEAR::Date > and AdoDB if not available. Rather than having a default setting to enable > them, we should have a setting to disable them. The difference on the > memory > footprint is significant and everyone should benefit from it. > > * Anything else? > > Just propose you changes to default settings. Now is the right time to do > it. > Last minute changes during the release process are always bad surprises. > > -- > LP > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |
From: Jonny B <jm...@no...> - 2008-09-24 14:36:40
|
Hi Lois-Philippe Well done and thanks for all your work on these new features - sorry i've been busy on some other stuff (again!) but hoping to Tiki more in the near future - my comments inline below... on 24/9/08 14:56, Louis-Philippe Huberdeau at lph...@dr... wrote: > Hello, > > Emerging from a discussion on IRC, I would reccommend we make all the default > setting changes on trunk as soon as possible so we can fully test them before > the release (still a few months out, which is good). > > We can expect trunk to become little unstable for a while, but many new > developments need to be tested throughoutly. fingers crossed... > * Themes > > Default theme should be made to one of the litecss-based themes, which is > supposed to be our future. > > Also, I am still waiting for Patrick's design to become more than a poster on > a wall. ;) Sounds good - thanks Gary too for all the lovely new themes! :) > * PDO & Date > > At this time, a special flag has to be added in local.php to enable it. I > think both should be made default if available, with fallback on PEAR::Date > and AdoDB if not available. Rather than having a default setting to enable > them, we should have a setting to disable them. The difference on the memory > footprint is significant and everyone should benefit from it. I enabled PDO when it arrived in trunk and all seemed well at first, especially on "small" tikis - i.e. new installs. But when i tried to use it on my big hairy tiki (updated from 1.8 originally, via 1.9, 2.0 and now 3.0) it just white-pages all the time. I think it might well have something to do with the PHP memory_limit, but then it started failing even on my local server, with a massive limit set (128MB i think). This was all a little while ago, and since then i've had to revert to AdoDB for everything, just to Get It Working. I'll come back with more if i get time to do more investigation... > * Anything else? > Just propose you changes to default settings. Now is the right time to do it. > Last minute changes during the release process are always bad surprises. > > -- > LP I'd really like to see: * AJAX at least moved out of "experimental" of not enabled by default. I have a small commit to make soon AJAX work in modules, and would suggest we try to upgrade xajax to v0.5 (currently in RC1 flavour) which might help with some of the problems people have found (i haven't) * I also have a little tiny commit to make which allows an "options" css file to be included after the main theme (feature_style_option). This makes it easy to do different "colour-ways" on existing theme/styles - You want tikineat in purple? - should be possible in a dozen or so definitions... Still have to do the admin page(s) for it * Choose between "magic" and the old admin (magic still doesn't work for me usually) * Working, non experimental WYSIWYG editor (sorry ;) Probably more, but out of time again - more soon i hope! jonny By the way - what's the plan with 2.1 - i thought there wasn't going to be a 2.1? |
From: Louis-Philippe H. <lph...@dr...> - 2008-09-24 14:47:49
|
> I'd really like to see: > > * AJAX at least moved out of "experimental" of not enabled by default. > I have a small commit to make soon AJAX work in modules, and would suggest > we try to upgrade xajax to v0.5 (currently in RC1 flavour) which might help > with some of the problems people have found (i haven't) I agree it's one of those things we would want. However, this discussion is about default changes, not wishlists. I don't think significant work was made on those features that make the decision of making them experimental any different. If you have time to improve them, I would be glad to see them improve ;) > > * I also have a little tiny commit to make which allows an "options" css > file to be included after the main theme (feature_style_option). This makes > it easy to do different "colour-ways" on existing theme/styles - You want > tikineat in purple? - should be possible in a dozen or so definitions... > Still have to do the admin page(s) for it Christine has been working on a color picker to change the theme colors. I don't know much of the details. Marc sent a message with more details a few days ago. > > * Choose between "magic" and the old admin (magic still doesn't work for me > usually) Can you explain the type of problems you have? > > * Working, non experimental WYSIWYG editor (sorry ;) Again... not a wishlist. Need people to work on it for decisions to change. This is likely not to change for 3.0 as I have heard of no master plan to solve this issue. Is there one? > > By the way - what's the plan with 2.1 - i thought there wasn't going to be > a 2.1? We had a security alert and had to do it. Few fixes went through. The point is to keep updates to a minimum. It was in fact "hopefully no 2.1", which would have been a good thing. No minor release means there is no problem significant enough to bother people with an other release. Thank you for your comments. -- LP > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |
From: Jonny B <jm...@no...> - 2008-09-26 12:19:48
|
Thanks LP - does that mean i can commit my WYSIWYG bugfixes there? Or have i missed the boat again? I am using trunk at the moment because of these problems... jb p.s. I've added a few more watches on dev.tw.o pages in case that's where these things get announced - any pages better than others? on 24/9/08 15:46, Louis-Philippe Huberdeau at lph...@dr... wrote: >> By the way - what's the plan with 2.1 - i thought there wasn't going to be >> a 2.1? > > We had a security alert and had to do it. Few fixes went through. The point is > to keep updates to a minimum. It was in fact "hopefully no 2.1", which would > have been a good thing. No minor release means there is no problem > significant enough to bother people with an other release. |
From: Stephane C. <se...@lo...> - 2008-09-24 15:12:39
|
Le Wed, Sep 24, 2008 at 10:37:25AM -0400, Louis-Philippe Huberdeau écrivait : > On September 24, 2008 10:10:52 Stephane Casset wrote: > > > * PDO & Date > > > > > > At this time, a special flag has to be added in local.php to enable it. I > > > think both should be made default if available, with fallback on > > > PEAR::Date and AdoDB if not available. Rather than having a default > > > setting to enable them, we should have a setting to disable them. The > > > difference on the memory footprint is significant and everyone should > > > benefit from it. > > > > For PDO we need to take care of Concat... Categories admin page is not > > working du to that, But have don't have time now for that. > > We need more testing, I didn't have any feed back. > > Can you explain a little more? I did try PDO early on and it seemed to work, > but since I create fresh installs often, I forgot to enable it for a while. > Now it seems broken. This is exactly why we need it as a default. Well try now, I thing I solved your pb... Well try to go to to the Categories Admin page, we need the concat operator... > > > * Anything else? > > > > Magic ? Don't know if it works, or if it is complete. > > Already there by default. Still some work in progress I guess. I will > let Marc comment on this as I havn't followed the development so much. > Obviously, we would need to start killing the old panels for people to > use magic more. Well as it is not working for every one, we should enable it by default but but a selector to disable it... > > And I might look dense but, we need to take some decision about PHP5 > > only stuff and about MySQL 5+ compatibility. > > > > From different discussions it seems parts of TikiWiki assume we have > > MySQL5+ only... > > > > So either we fix these area, or we assume openly that TikiWiki requires > > MySQL5+ and we dump AdoDB and we implement some major performance > > optimizations... > > I think we should support the supported versions. MySQL still supports 4.1. I > think most of tiki runs fine under 4.1 as it supports subqueries, which is > the major thing that starts popping up all over the code. (I am fully aware > that I started using them and broke 4.0 compatibility). Well make it MySQL4.1+ if you want but it is still MySQL only. So either we fix it and make it work with PostgreSQL, Oracle, etc. or we state plain and simple : « Tikiwiki is MySQL only with version 4.1+. » But it needs to be done. Because I have some people here that says Tikiwiki is not working... I have PostgreSQL and it is not working... :( it is bad for TikiWiki. A+ -- Stéphane Casset LOGIDÉE sàrl Se faire plaisir d'apprendre 1a, rue Pasteur Tel : +33 388 23 69 77 ca...@lo... F-67540 OSTWALD Fax : +33 388 23 69 77 http://logidee.com |
From: Louis-Philippe H. <lph...@dr...> - 2008-09-24 15:38:12
|
On September 24, 2008 10:53:26 Stephane Casset wrote: > Le Wed, Sep 24, 2008 at 10:37:25AM -0400, Louis-Philippe Huberdeau écrivait : > > On September 24, 2008 10:10:52 Stephane Casset wrote: > > > > * PDO & Date > > > > > > > > At this time, a special flag has to be added in local.php to enable > > > > it. I think both should be made default if available, with fallback > > > > on PEAR::Date and AdoDB if not available. Rather than having a > > > > default setting to enable them, we should have a setting to disable > > > > them. The difference on the memory footprint is significant and > > > > everyone should benefit from it. > > > > > > For PDO we need to take care of Concat... Categories admin page is not > > > working du to that, But have don't have time now for that. > > > We need more testing, I didn't have any feed back. > > > > Can you explain a little more? I did try PDO early on and it seemed to > > work, but since I create fresh installs often, I forgot to enable it for > > a while. Now it seems broken. This is exactly why we need it as a > > default. > > Well try now, I thing I solved your pb... > > Well try to go to to the Categories Admin page, we need the concat > operator... Fixed. > > > > > * Anything else? > > > > > > Magic ? Don't know if it works, or if it is complete. > > > > Already there by default. Still some work in progress I guess. I will > > let Marc comment on this as I havn't followed the development so much. > > Obviously, we would need to start killing the old panels for people to > > use magic more. > > Well as it is not working for every one, we should enable it by default > but but a selector to disable it... It's meant to be a replacement and only affects administrators. I don't think that's the type of thing we want to make disableable... would cause work duplication in maintaining two administration panels. We need to choose either of them, not both. > > > > And I might look dense but, we need to take some decision about PHP5 > > > only stuff and about MySQL 5+ compatibility. > > > > > > From different discussions it seems parts of TikiWiki assume we have > > > MySQL5+ only... > > > > > > So either we fix these area, or we assume openly that TikiWiki requires > > > MySQL5+ and we dump AdoDB and we implement some major performance > > > optimizations... > > > > I think we should support the supported versions. MySQL still supports > > 4.1. I think most of tiki runs fine under 4.1 as it supports subqueries, > > which is the major thing that starts popping up all over the code. (I am > > fully aware that I started using them and broke 4.0 compatibility). > > Well make it MySQL4.1+ if you want but it is still MySQL only. > So either we fix it and make it work with PostgreSQL, Oracle, > etc. or we state plain and simple : > « Tikiwiki is MySQL only with version 4.1+. » > But it needs to be done. > > Because I have some people here that says Tikiwiki is not working... > I have PostgreSQL and it is not working... :( it is bad for TikiWiki. I agree on this one. I think the discussions ended with : we advertise 3.0 as MySQL only, and give a hint that this will be permanent from 4.x unless the other communities jump in and help us get the support for other DBs working. -- LP |
From: Kerr, M. E (Mike) <mik...@ve...> - 2008-09-24 17:49:14
|
> > > I think we should support the supported versions. MySQL still supports > > > 4.1. I think most of tiki runs fine under 4.1 as it supports > subqueries, > > > which is the major thing that starts popping up all over the code. (I > am > > > fully aware that I started using them and broke 4.0 compatibility). > > > > Well make it MySQL4.1+ if you want but it is still MySQL only. > > So either we fix it and make it work with PostgreSQL, Oracle, > > etc. or we state plain and simple : > > < Tikiwiki is MySQL only with version 4.1+. > > > But it needs to be done. > > > > Because I have some people here that says Tikiwiki is not working... > > I have PostgreSQL and it is not working... :( it is bad for TikiWiki. > > I agree on this one. I think the discussions ended with : we advertise 3.0 > as > MySQL only, and give a hint that this will be permanent from 4.x unless > the > other communities jump in and help us get the support for other DBs > working. We should not remove the code that makes Tiki extensible for other databases. Granted, only MySQL is truly fully supported by the Tiki community, the more people we draw to the project, the more diverse it will become. Advertising Tiki as a MySQL-only shop will tell anybody wanting to join the community that can't use MySQL that they aren't welcome. I say leave the code in, say it has the possibility of using those other databases, and that we're looking for good people who can assist with shoring up other-db support. Sure, we can state explicitly that with the state of the code, Tiki supports MySQL from 4.1.x+, but we should not shy away from saying the framework is in place to support other databases, its just that there hasn't been enough expertise to develop those areas. If you come out and say right off the bat that Tiki is Mysql 5.x only, I can assure you there will be people that will immediately bypass the project. My understanding is that there are still many many many Tiki installations that are running 4.1 (apparently also 4.0). Just within my company alone, we use Oracle, Sybase, MSSQL, and MySQL. If I can ever get around to it, I'd like to experiment to get them to work. I'm sure we are not the only ones who have an IT group that pushes corporate users to commercial solutions. I understand that having support for multiple versions of the same database is difficult to maintain, but then so is maintaining code for multiple databases. Abstraction is nothing new to us, so making a framework to support 4.1 vs. 5.0 or php4 vs. php5 should be fairly trivial in the grand scheme of things. Mike. ______________________________ Mike Kerr Sr. Internet Network Engineer verizonbusiness (703) 886-2251 mik...@ve... "I didn't come here to be ordinary." > > -- > LP > > ------------------------------------------------------------------------ - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |
From: Kerr, M. E (Mike) <mik...@ve...> - 2008-09-24 17:54:49
|
> * Working, non experimental WYSIWYG editor (sorry ;) My understanding is that part of the problem is that we are relying on external libraries, and they convert whatever is in the wysiwyg window into HTML. Then we have to convert that to Tiki, then convert Tiki back to HTML. At the TikiFest this past weekend, I threw up a wishlist idea to have a button to import a Word doc, or to import a PDF, or any of a list of formats. I think this could be facilitated, as well as all of the problems with the wysiwyg, by using an intermediary markup. Essentially a standard middle-man. Theoretically this could become a Tiki-sponsored open source library project on its own for PHP, allowing both the import and export of various document formats to and from Tiki (or any other wiki markup language). This would eliminate our perpetual problems converting Wiki into PDF. The solution is to use XML as the intermediary. Come up with a standard markup base and convert the wysiwyg into XML, then convert from XML to Tiki. Convert Tiki to XML and XML to Word, PDF, whatever. Makes it a LOT easier than working with loosie-goosy HTML, and provides so many extra benefits. Granted, you're not going to necessarily be able to convert some of the more advanced items in Word or PDF to something Tiki can handle, but enterprising people can extend the markup as much as they want, it just won't get handled. If another Wiki wants to use some of these advanced things from a Word doc, then they can write their markup and directly use whatever the xml markup designates. Imagine converting a Word doc that has a table of contents? No problem now. Personally, I think this is the solution to the wysiwyg problem. I've got much too much on my plate to really put any time or effort into it, but like-minded, motivated individuals, can probably set to work on the lib set for 4.0 (or even 3.0) and have significant success. The best part is that XML parsing is built-in to PHP already. Mike. ______________________________ Mike Kerr Sr. Internet Network Engineer verizonbusiness (703) 886-2251 mik...@ve... "I didn't come here to be ordinary." |
From: Louis-Philippe H. <lph...@dr...> - 2008-09-24 18:09:52
|
> The solution is to use XML as the intermediary. Come up with a standard > markup base and convert the wysiwyg into XML, then convert from XML to > Tiki. Convert Tiki to XML and XML to Word, PDF, whatever. Makes it a > LOT easier than working with loosie-goosy HTML, and provides so many > extra benefits. > > Granted, you're not going to necessarily be able to convert some of the > more advanced items in Word or PDF to something Tiki can handle, but > enterprising people can extend the markup as much as they want, it just > won't get handled. If another Wiki wants to use some of these advanced > things from a Word doc, then they can write their markup and directly > use whatever the xml markup designates. Imagine converting a Word doc > that has a table of contents? No problem now. > > Personally, I think this is the solution to the wysiwyg problem. I've > got much too much on my plate to really put any time or effort into it, > but like-minded, motivated individuals, can probably set to work on the > lib set for 4.0 (or even 3.0) and have significant success. The best > part is that XML parsing is built-in to PHP already. I have this on my plate as well. I have a few pages of notes already forming a plan. I just need more time to get to it. No guarentee on this being ready and stable for 3.0 thought. It requires major changes in the parser... basically a whole new parser... and impact on tikiwiki is significant. The base idea is to get the page content stored as XML in the database. Any editor playing with the content has to store in a common format, which would be tailored to be as expressive as the tiki syntax itself. It opens up many possibilities, but the picture is not fully clear. I need to take more notes still. -- LP |
From: Kerr, M. E (Mike) <mik...@ve...> - 2008-09-24 17:54:58
|
> Emerging from a discussion on IRC, I would reccommend we make all the > default > setting changes on trunk as soon as possible so we can fully test them > before > the release (still a few months out, which is good). +1, we should start thinking about freezing the feature set for 3.0. Personally, I would like to see anything that isn't on that feature list, or stuff that is considered experimental, be completely removed from the tree and left in trunk. It just makes things confusing for people I think. Mike. ______________________________ Mike Kerr Sr. Internet Network Engineer verizonbusiness (703) 886-2251 mik...@ve... "I didn't come here to be ordinary." |
From: Louis-Philippe H. <lph...@dr...> - 2008-09-24 18:05:25
|
On September 24, 2008 13:37:13 Kerr, Michael E (Mike) wrote: > > Emerging from a discussion on IRC, I would reccommend we make all the > > default > > setting changes on trunk as soon as possible so we can fully test them > > before > > the release (still a few months out, which is good). > > +1, we should start thinking about freezing the feature set for 3.0. > > Personally, I would like to see anything that isn't on that feature > list, or stuff that is considered experimental, be completely removed > from the tree and left in trunk. It just makes things confusing for > people I think. 3.0 is not branched from trunk yet and now is not a good time to call a feature freeze. The release is too far out. The feature freeze will be made early-March. But until then, we keep it quite stable by using experimental branches. -- LP > > Mike. > > ______________________________ > Mike Kerr > Sr. Internet Network Engineer > verizonbusiness > (703) 886-2251 > mik...@ve... > "I didn't come here to be ordinary." > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |
From: Marc L. <ma...@ma...> - 2008-09-24 20:15:31
|
On Wed, Sep 24, 2008 at 12:37 PM, Kerr, Michael E (Mike) <mik...@ve...> wrote: >> Emerging from a discussion on IRC, I would reccommend we make all the >> default >> setting changes on trunk as soon as possible so we can fully test them >> before >> the release (still a few months out, which is good). > > +1, we should start thinking about freezing the feature set for 3.0. > > Personally, I would like to see anything that isn't on that feature > list, or stuff that is considered experimental, be completely removed > from the tree and left in trunk. It just makes things confusing for > people I think. > First off, we don't really have an official list of what will be in 3.0 I think the question/definition/guidelines of: 1- "feature freeze" vs "business as usual" 2- experimental vs stable feature 3- major feature vs minor feature. are not black and white enough to make global decisions like this (removing things). We would have to have much clearer guidelines as to what each thing means. Otherwise, when you go through the list, it's very difficult to reach a consensus. Something may feel experimental to me but stable to someone else. What I feel is a bug fix (doesn't work), someone else may feel it's a feature enhancement (wasn't coded that way). What do you do about experimental/new/unstable options of a generally more stable feature? We set a long lead time for the upcoming release (http://dev.tikiwiki.org/roadmap) so people can self organize and make sure that things are ready in time. Assuming we are 1 month away from a planned release, some new features are OK and some are not. For a very complex and far reaching feature, it could make sense for the developer to wait for the next round (4.0). But if it's a minor feature, 1 month is sufficient. Furthermore, removing features is not that easy. It takes time, and no one is very motivated to do that. And people that use those features will be unhappy. They may also end up not upgrading. It's just not that simple. About experimental: I think it's better to keep these features in the main code base. Experience has shown that stuff that is not in the main code base (in mods.tikiwiki.org) tends to become unusable and unmaintained (if that's not the reason it was put there in the first place!). I think tagging features as experimental (which is a judgment call in itself) is a great way to inform end-users about potential risks and instabilities, all while keeping in the main code base and still being used, tested and improved upon. So, again. We need general guidelines such as these: http://dev.tikiwiki.org/To+Mods+Or+Not+To+Mods But for what determines : 1- "feature freeze" vs "business as usual" 2- experimental vs stable feature 3- major feature vs minor feature. This is also to help people to know if people should commit to "stable" branches/2.0 or trunk. http://dev.tikiwiki.org/Where+to+commit Best regards, -- Marc Laporte http://MarcLaporte.com http://TikiWiki.org/MarcLaporte http://AvanTech.net http://OurWiki.net |
From: Kerr, M. E (Mike) <mik...@ve...> - 2008-09-24 18:20:35
|
> I have this on my plate as well. I have a few pages of notes already > forming a > plan. I just need more time to get to it. No guarentee on this being ready > and stable for 3.0 thought. It requires major changes in the parser... > basically a whole new parser... and impact on tikiwiki is significant. > > The base idea is to get the page content stored as XML in the database. > Any > editor playing with the content has to store in a common format, which > would > be tailored to be as expressive as the tiki syntax itself. It opens up > many > possibilities, but the picture is not fully clear. I need to take more > notes > still. Sounds good. Please don't think you have to come up with and flesh out these things on your own... Mike. ______________________________ Mike Kerr Sr. Internet Network Engineer verizonbusiness (703) 886-2251 mik...@ve... "I didn't come here to be ordinary." |
From: Jonny B <jm...@no...> - 2008-09-26 12:13:38
|
<strong>+1</strong> on 24/9/08 19:15, Kerr, Michael E (Mike) at mik...@ve... wrote: >> I have this on my plate as well. I have a few pages of notes already >> forming a >> plan. I just need more time to get to it. No guarentee on this being > ready >> and stable for 3.0 thought. It requires major changes in the parser... >> basically a whole new parser... and impact on tikiwiki is significant. >> >> The base idea is to get the page content stored as XML in the > database. >> Any >> editor playing with the content has to store in a common format, which >> would >> be tailored to be as expressive as the tiki syntax itself. It opens up >> many >> possibilities, but the picture is not fully clear. I need to take more >> notes >> still. > > Sounds good. Please don't think you have to come up with and flesh out > these things on your own... > > Mike. > > ______________________________ > Mike Kerr > Sr. Internet Network Engineer > verizonbusiness > (703) 886-2251 > mik...@ve... > "I didn't come here to be ordinary." > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |
From: <ma...@gm...> - 2008-09-26 12:26:19
|
+++1 and as with Mike I am very willing to help out, in any way you want. I think this is an absolutely fantastic idea. From a content base of XML so many things become easier with TW. Matthew (MatWho) On 26 Sep 2008, at 13:12, Jonny B wrote: > > <strong>+1</strong> > > > on 24/9/08 19:15, Kerr, Michael E (Mike) at mik...@ve... > wrote: > >>> I have this on my plate as well. I have a few pages of notes already >>> forming a >>> plan. I just need more time to get to it. No guarentee on this being >> ready >>> and stable for 3.0 thought. It requires major changes in the >>> parser... >>> basically a whole new parser... and impact on tikiwiki is >>> significant. >>> >>> The base idea is to get the page content stored as XML in the >> database. >>> Any >>> editor playing with the content has to store in a common format, >>> which >>> would >>> be tailored to be as expressive as the tiki syntax itself. It >>> opens up >>> many >>> possibilities, but the picture is not fully clear. I need to take >>> more >>> notes >>> still. >> >> Sounds good. Please don't think you have to come up with and flesh >> out >> these things on your own... >> >> Mike. >> >> ______________________________ >> Mike Kerr >> Sr. Internet Network Engineer >> verizonbusiness >> (703) 886-2251 >> mik...@ve... >> "I didn't come here to be ordinary." >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win >> great prizes >> Grand prize is a trip for two to an Open Source event anywhere in >> the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Tikiwiki-devel mailing list >> Tik...@li... >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |
From: Kerr, M. E (Mike) <mik...@ve...> - 2008-09-24 20:40:34
|
> > +1, we should start thinking about freezing the feature set for 3.0. > > > > Personally, I would like to see anything that isn't on that feature > > list, or stuff that is considered experimental, be completely removed > > from the tree and left in trunk. It just makes things confusing for > > people I think. > > First off, we don't really have an official list of what will be in 3.0 > > I think the question/definition/guidelines of: > 1- "feature freeze" vs "business as usual" > 2- experimental vs stable feature > 3- major feature vs minor feature. > are not black and white enough to make global decisions like this > (removing things). I agree, and perhaps I didn't word things as well as I should have. What I meant was that we should start discussing it. The ultimate freeze wouldn't happen until next year when we're a month or two out from release. No harm in discussing and planning though. > may feel it's a feature enhancement (wasn't coded that way). What do > you do about experimental/new/unstable options of a generally more > stable feature? That is what (in my opinion) interim .1, .2, .3 releases are for, refinement of .0 stuff and bug fixes so that they work as intended. > Furthermore, removing features is not that easy. It takes time, and no > one is very motivated to do that. And people that use those features > will be unhappy. They may also end up not upgrading. It's just not > that simple. I guess I'm referring in this instance to stuff that falls in the Experimental tab. Let's make a decision before the freeze as to what is working, what is buggy to the point of not being supportable, what hasn't been developed at all since 2.0. We've got a lot of time between now and then. Some things in the Experimental tab have been around and working for the most part since 1.9 (3D browser for example), so maybe put it in a different tab. What I'm requesting is that stuff that is truly Experimental...maybe we keep the code - I have no problem with that - but just get rid of the Experimental menu for the release, but keep the tab in trunk. >From a marketing and support perspective, I have never seen a piece of software out there that has an "Experimental" menu where it's buyer beware. That is usually reserved for the CSV where people can get cutting edge stuff that isn't production-worthy. If it's stable, and working more or less as intended, then make it a real feature and let's work on refining it. Mike. ______________________________ Mike Kerr Sr. Internet Network Engineer verizonbusiness (703) 886-2251 mik...@ve... "I didn't come here to be ordinary." |
From: Gary Cunningham-L. <ga...@cu...> - 2008-09-25 06:14:26
|
Is there a reason why the magic topbar is displayed at the top of the site on all pages rather than inside the center column on its own page as the old admin pages (and other Tiki features/sections) are? Unless there is a good reason, I think it should follow the logic of Tiki organization and be on its own page. The functionality doesn't change, wherever the menu is; opening menu items always displays linked content in the center column. The attached image file shows a quick cut and paste of include tiki-admin_bar.tpl into #col1 .content (middle column). There's some wrapping of menu items but it works fine so the wrapping isn't a problem, I think. (Maybe the "tip" -- "Configure blogs" in this image -- could be reworked as a :hover or something. On a wide page, this tip is at the right side of the menu's top row.) A related question: I wonder what the rationale is for this menu, etc., to have its own coloring and so on rather than go for consistency with theme styles. I think it would be better if it didn't look like something external added as a patch. Not to say I don't like the appearance; I do, and think maybe a "magic" theme building on this would be great. I understand that in prototyping, styling is needed, but in production probably it should look integral, not after-market. -- Gary Marc Laporte wrote: > Hi! > > Magic is on by default, but it's not yet to the point of making the > old admin panel obsolete. > > We need a setting that shows & hides the top admin bar. > http://dev.tikiwiki.org/magic > > Can anyone step up for this? > > Thanks! > > M ;-) > > >>> Magic ? Don't know if it works, or if it is complete. >> Already there by default. Still some work in progress I guess. I will let Marc >> comment on this as I havn't followed the development so much. Obviously, we >> would need to start killing the old panels for people to use magic more. >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.7.1/1688 - Release Date: 2008/09/24 6:29 > |
From: luci a. l. d' b. <sf...@gr...> - 2008-09-25 12:10:25
|
hello, On 24/09/08 16:37, Louis-Philippe Huberdeau wrote: > I think we should support the supported versions. MySQL still supports 4.1. I > think most of tiki runs fine under 4.1 as it supports subqueries, which is > the major thing that starts popping up all over the code. (I am fully aware > that I started using them and broke 4.0 compatibility). > > I (and I think Xavi too) was pretty disappointed to find out that 2.0 nomore fully supports MySQL 4.x (actually I first thought it's only mysql classic vs mysqli problem)... are the benefits of using these "subqueries" so great that we have to drop standard SQL support for 4.0 and say we support MySQL 4.1+ only ? are the subqueries supported in other DB engines than MySQL ? luci |
From: Louis-Philippe H. <lph...@dr...> - 2008-09-25 12:17:28
|
On September 25, 2008 08:10:18 luci aka luciash d' being wrote: > hello, > > On 24/09/08 16:37, Louis-Philippe Huberdeau wrote: > > I think we should support the supported versions. MySQL still supports > > 4.1. I think most of tiki runs fine under 4.1 as it supports subqueries, > > which is the major thing that starts popping up all over the code. (I am > > fully aware that I started using them and broke 4.0 compatibility). > > I (and I think Xavi too) was pretty disappointed to find out that 2.0 > nomore fully supports MySQL 4.x (actually I first thought it's only > mysql classic vs mysqli problem)... > > are the benefits of using these "subqueries" so great that we have to > drop standard SQL support for 4.0 and say we support MySQL 4.1+ only ? Yes. Sometimes they can be avoided by using more joins, but there are some cases where not using them would require a lot more PHP code (and slower processing). > > are the subqueries supported in other DB engines than MySQL ? Yes, MySQL has been the only engine not to support them for long time. All other engines supported subqueries back when MySQL's first version came out (12 years ago?). -- LP > > luci > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |
From: luci a. l. d' b. <sf...@gr...> - 2008-09-25 12:18:41
|
hi, just a small thing for Admin → Wiki (lot of non-english wiki users ask about it) could the wiki link format support be "complete" by default instead of "english" ? (is it even necessary to let the user choose instead of making it complete for all ?) just my 2 CZK luci |
From: Louis-Philippe H. <lph...@dr...> - 2008-09-25 12:21:56
|
+1 On September 25, 2008 08:18:31 luci aka luciash d' being wrote: > hi, > > just a small thing for Admin → Wiki (lot of non-english wiki users ask > about it) > > could the wiki link format support be "complete" by default instead of > "english" ? > (is it even necessary to let the user choose instead of making it > complete for all ?) > > > just my 2 CZK > > luci > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |