From: Michael H. <mic...@el...> - 2005-04-04 12:46:32
|
Hi all, following up under a more fitting topic. Milan Babuskov wrote: >> I will gladly add the things that keep *me* from eating my own >> dog-food (use FR for my day-to-day Firebird work) to the wiki. > > I think it is far more productive to first start some discussion > here. After we get to some conclusions, we can place the items in > tracker (RFE) or, if it is too complicated, place it in the Wiki. Ok, I will give you a list, probably not complete though. See below why I don't think it is purely a matter of on-list discussion or SF tracker. This list is in *my* personal order of importance: 1) User management. As this one is most important for me, I will/would start on it ASA the new DBH is in place. 2) Creation, recreation and dropping of databases, while the registration info remains intact. 3) Database property page (showing page size, buffer count, sweep interval, forced writes, ODS, transaction infos, ...) 4) Editable grid. 5) UI to register for and log events. > As you can notice, we are waiting for Gregory. Hopefully not much > longer. After the base is set, we will go back to our own speed. I'm > very quick at adding new code... as soon as stage is setup, you'll > see much faster development. Nando is also very productive, and so > are you. I also believe the after that point, we will be able to give > predictions about when would some feature be implemented. I'm sorry > to have to state the obvious, but Gregory is too unpredictable. Milan, I'm aware of the situation. But in any case, I believe we need a roadmap of some sort. At least a very basic outlook on things to come - even more for our (prospective) users than for ourselves - and we need it in a place that is easy to find and to work with. Consider someone who reads that a new version of FR has been released, say on firebirdsql.org or freshmeat or some similar location. They don't read the mailing list. The list archive or the SF tracker are neither fast nor easy to work with. IMHO there should be something on the homepage, and failing that in the wiki, that allows them to quickly decide whether FlameRobin is worth watching out for. Right now nobody knows when to expect things like the editable grid, even when it is in the tracker. I don't mean a hard date, but something like: - version 0.3, expected mid to end April 2005 (option dialog, execution of selected statements, ...) - version 0.5, expected end of May 2005 (integration of new DBH object structure, should facilitate faster development) - version 0.6, expected ??? (user management, ...) ... - version 1.0, expected [date of FB conference 2005] I understand your point > I also believe the after that point, we will be able to give > predictions about when would some feature be implemented but I think we could decide even before that on the relative importance of features, and the feasibility of them - given the little time to the FB conference. Perhaps most of the guys on this list have a wish list for FR, and knowing most of those wished-for features beforehand might well improve the design of FR. Does that sound reasonable? Best -- Michael Hieke |
From: Milan B. <mi...@km...> - 2005-04-05 21:34:59
|
Michael Hieke wrote: > Ok, I will give you a list, probably not complete though. See below why > I don't think it is purely a matter of on-list discussion or SF tracker. I didn't say it is "purely a matter of on-list discussion or SF tracker". I wrote that we should first discuss ideas here, and then place them in tracker (for simple things) or Wiki (for complicated). I agree that Roadmap(tm) should go to the Wiki, but we should first discuss it here. We can throw all 1.0 features on the heap, sort the order of making them, and then write a roadmap. Using Wiki for this process is not feasible IMHO, since we shouldn't place questions, opinions and doubts there. We should place the definite decisions. > This list is in *my* personal order of importance: > > 1) User management. As this one is most important for me, I will/would > start on it ASA the new DBH is in place. > > 2) Creation, recreation and dropping of databases, while the > registration info remains intact. > > 3) Database property page (showing page size, buffer count, sweep > interval, forced writes, ODS, transaction infos, ...) > > 4) Editable grid. > > 5) UI to register for and log events. Ok, here's my list of features I need a lot. Of course, I will work on some others too: 1. DDL generator for each object 2. Generating "recreate view" script that drops all the dependencies (and privileges) and the view itself, creates the view, and get it all back. This requires that 1) is done 3. "Indices page" for table properties window. I'm not sure, but I think someone else also volunteered for this one? 4. Improve Drag&drop stuff for SQL Editor. It will be a very powerful feature, but it needs much more polish. 5. Logging changes to in-database table: flamerobin_log 6. Duplicate registration info: When you have the same server, user, pass, role, charset, just different database. > Milan, I'm aware of the situation. But in any case, I believe we need a > roadmap of some sort. At least a very basic outlook on things to come - > even more for our (prospective) users than for ourselves - and we need > it in a place that is easy to find and to work with. Agreed. Here we have your list and mine list. I'd like that Nando send his list too. Then, we should discuss if there is something else that also needs to go in 1.0, beside these items. After that, we create a Roadmap, and publish it in Wiki. > IMHO there should be something on the homepage, and failing that in the > wiki Failing? I didn't get this one. IMHO, wiki is very good for these things since anyone of us can easily edit it. We just need a "Roadmap" link on main page that leads to Roadmap page in Wiki and we're done. > - version 0.3, expected mid to end April 2005 (option dialog, execution > of selected statements, ...) > - version 0.5, expected end of May 2005 (integration of new DBH object > structure, should facilitate faster development) > - version 0.6, expected ??? (user management, ...) > ... > - version 1.0, expected [date of FB conference 2005] For now, I'd leave dates out of it. We just need a roadmap: feature X in version A, feature Y in version B. We might put a date for 1.0 though. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Michael H. <mic...@el...> - 2005-04-06 08:15:11
|
Milan Babuskov wrote: >> Ok, I will give you a list, probably not complete though. See below >> why I don't think it is purely a matter of on-list discussion or SF >> tracker. > > I didn't say it is "purely a matter of on-list discussion or SF > tracker". I wrote that we should first discuss ideas here, and then > place them in tracker (for simple things) or Wiki (for complicated). Yes, I understood that. > Using Wiki for this process is not feasible IMHO, since we shouldn't > place questions, opinions and doubts there. We should place the > definite decisions. [snip] >> IMHO there should be something on the homepage, and failing that in the >> wiki > > Failing? I didn't get this one. IMHO, wiki is very good for these things > since anyone of us can easily edit it. We just need a "Roadmap" link on > main page that leads to Roadmap page in Wiki and we're done. Ok, that's a good solution. With "failing" I meant that just a page somewhere in the wiki is not easy to find, so I would prefer a prominent place on the homepage. A link to the correct wiki page is that, of course. But - maybe I'm misunderstanding you - above lines seem to me somewhat contradictory. Either we don't want to have "questions, opinions and doubts there", or it's good "since anyone of us can easily edit it". A decided upon roadmap is surely static enough to be a HTML page? But enough of that, roadmap on the wiki is fine with me. Maybe I start to like the wiki when I start using it ;-) > For now, I'd leave dates out of it. We just need a roadmap: feature X in > version A, feature Y in version B. We might put a date for 1.0 though. Ok. Best -- Michael Hieke |
From: Milan B. <mi...@km...> - 2005-04-06 14:32:35
|
Michael Hieke wrote: > But - maybe I'm misunderstanding you - above lines seem to me somewhat > contradictory. Either we don't want to have "questions, opinions and > doubts there", or it's good "since anyone of us can easily edit it". A > decided upon roadmap is surely static enough to be a HTML page? As you say yourself, it has to first be "decided upon". I'd like that we first agree on some general points here. After that, we put a Wiki page. After that, we edit the Wiki page, adding new things that come along (like that case-sensitivity problem, that Igor Gorbounov sent mail about). For each of these items, we should discuss: who will do it and when it will come. For example, I haven't got the slightest idea who is going to work on case-sensitivity problem, or in which 0.x version it should appear. So I'll start some version suggestions here: 0.2.5 last release with old DBH. TODO: Fix the options dialog? 0.2.6-0.2.9 unofficial releases while porting code to new DBH 0.3.0 first stable version with new DBH 0.4.0-0.8.x various alpha releases with adding missing features 0.9.0-0.9.x BETA stage, all 1.0 features implemented, doing testing, bugfixing, polishing, maybe translations 1.0.0 :) If everyone agrees with this, we need to work out 0.4 - 0.8 in detail. Separate it into 5 steps: 0.4, 0.5, 0.6, 0.7, 0.8 and decide which features will go in which version... OR ...just decide which features go into version 0.8 and increase versions gradually to it. Even if we reach 0.8 and miss something, we still have 0.8-0.9 period to add needed stuff. Once we agree on all this, we can make the initial Roadmap document in Wiki, and later just edit to add new stuff, mark what is done, etc. -- Milan Babuskov http://abrick.sourceforge.net |
From: Michael H. <mic...@el...> - 2005-04-06 16:10:33
Attachments:
OptionDlgXP.png
|
Milan Babuskov wrote: > So I'll start some version suggestions here: > > 0.2.5 last release with old DBH. TODO: Fix the options dialog? I have started on rewriting OptionDialog class, using the following layout: +----------------------------------------------------------+ | +-----------+ +----------------------------------------+ | | | | | B | | | | | +----------------------------------------+ | | | | +----------------------------------------+ | | | | | | | | | | | | | | | | | | | | | A | | | | | | | | | | | | | | C | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-----------+ +----------------------------------------+ | | +--------+ +--------+ | | +--------+ +--------+ | +----------------------------------------------------------+ with A being a wxTreeCtrl, B being the wxPanel for the category (but only one for all panes), and C being the control with the panes. Selecting a new tree node in A will update the caption of B and show the corresponding panes in C (and hide all others). For now I have implemented a new Optionbook class (descends like wxNotebook, wxChoicebook and wxListbook from wxBookctrlBase), because I could not find a way to hide the tabs and border of a wxNotebook under MSW. But maybe a sizer with all the wxPanels inside and adjusted size hints will suffice. I do also look into using wxXmlDocument for the parsing of the config file. This together with the wxTreectrl allows for subcategories ("Code Completion" under "SQL Editor"). Right now it's maybe 25% done (see screenshot), but I hope it won't take too long to complete. Once it's finished I will zip the sources and post them. If 0.2.5 should be released earlier I suggest you revert to the OptionDialog version before my changes, because I have not found a way to make wxListbook work the way it should. In that case 0.2.5 should not be released for Mac OS X. > 0.2.6-0.2.9 unofficial releases while porting code to new DBH > 0.3.0 first stable version with new DBH > 0.4.0-0.8.x various alpha releases with adding missing features > 0.9.0-0.9.x BETA stage, all 1.0 features implemented, doing testing, > bugfixing, polishing, maybe translations > > 1.0.0 :) Sounds good. I assume the restructuring and move to flamerobin CVS falls into 0.2.6-0.3.0 timeframe as well? Best -- Michael Hieke |
From: Milan B. <mi...@km...> - 2005-04-07 06:57:38
|
Michael Hieke wrote: > I have started on rewriting OptionDialog class Looks ok. > Once it's finished I will zip the sources and post them. Or commit to "mghie" module in CVS. > If 0.2.5 should be released earlier I suggest you revert to the > OptionDialog version before my changes, because I have not found a way > to make wxListbook work the way it should. In that case 0.2.5 should > not be released for Mac OS X. 0.2.5 will be released when Gregory posts his code. It is only because of fact that 0.2.4 has some ugly bugs. Until new DBH is up and running, people should have something useful. >> 0.2.6-0.2.9 unofficial releases while porting code to new DBH >> 0.3.0 first stable version with new DBH >> 0.4.0-0.8.x various alpha releases with adding missing features >> 0.9.0-0.9.x BETA stage, all 1.0 features implemented, doing testing, >> bugfixing, polishing, maybe translations >> > Sounds good. I assume the restructuring and move to flamerobin CVS > falls into 0.2.6-0.3.0 timeframe as well? Yes. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Milan B. <mi...@km...> - 2005-04-07 14:04:46
|
Michael Hieke wrote: > I have started on rewriting OptionDialog class, using the following layout: [snip] > with A being a wxTreeCtrl, B being the wxPanel for the category (but > only one for all panes), and C being the control with the panes. > Selecting a new tree node in A will update the caption of B and show the > corresponding panes in C (and hide all others). For now I have > implemented a new Optionbook class (descends like wxNotebook, > wxChoicebook and wxListbook from wxBookctrlBase) FWIW, it appears that there were already few attempts to write a wxTreebook control, but I wasn't able to find any code, since links are broken: http://lists.wxwidgets.org/archive/wx-dev/msg24183.html http://lists.wxwidgets.org/archive/wx-users/msg11627.html http://lists.wxwidgets.org/archive/wx-dev/msg24245.html -- Milan Babuskov http://abrick.sourceforge.net |
From: Michael H. <mic...@el...> - 2005-04-08 07:54:22
Attachments:
FROptionDlgW2k.png
|
Milan Babuskov wrote: > FWIW, it appears that there were already few attempts to write a > wxTreebook control I know, but that doesn't help us. There are different reasons why I want to replace wxListbook, and all but the first are problems of wxChoicebook (and wxTreebook) as well: 1) wxListbook uses a wxListView for the image bar, which is a generic control != wxMSW. It does not look good, especially on Mac OS X. A good icon bar would look like in the Mozilla prefs dialog (whole selected image has coloured background, not only the caption). wxListView has problems with layout and automatic sizing too. 2) wxXXXbook uses hard-coded (and too small) space between navigation control and page area. This space also messes up the computation of needed client rect and control placement. To see this in action run the notebook demo of wxWidgets, press [Ctrl+2] to switch to wxListbook, and resize the frame. You will see the space magically appear, with controls jumping around. 3) wxXXXbook != wxNotebook has problems with keyboard navigation. I have added bug #1167559 to wxWidgets tracker; one wx developer tried to fix it already, and it seems hard (he gave up). 4) The page area is always whole client rect minus navigation control. This makes a layout like in the screenshot (description is one panel for all pages, updated when page changes) impossible. Best -- Michael Hieke |
From: Milan B. <mi...@km...> - 2005-04-08 18:20:52
|
Michael Hieke wrote: > 4) The page area is always whole client rect minus navigation control. > This makes a layout like in the screenshot (description is one panel for > all pages, updated when page changes) impossible. I like the screenshot a lot, so please keep going in that direction :) -- Milan Babuskov http://abrick.sourceforge.net |
From: marius p. <ma...@re...> - 2005-04-07 08:15:15
|
Milan Babuskov wrote: > Michael Hieke wrote: > >> But - maybe I'm misunderstanding you - above lines seem to me somewhat >> contradictory. Either we don't want to have "questions, opinions and >> doubts there", or it's good "since anyone of us can easily edit it". >> A decided upon roadmap is surely static enough to be a HTML page? > > ... > 1.0.0 :) > > Once we agree on all this, we can make the initial Roadmap document in > Wiki, and later just edit to add new stuff, mark what is done, etc. > is already on the wiki (can be edited) http://www.flamerobin.org/dokuwiki/doku.php?id=wiki:roadmap Alex could you add it to the news page :) Flamerobin roadmap Flamerobin developers are working on the to do list : Document is located ... (you can take a snippet from roadmap too...) -- Regards, Marius - roadmap to world domination |
From: Milan B. <mi...@km...> - 2005-04-07 13:24:06
|
marius popa wrote: >>>But - maybe I'm misunderstanding you - above lines seem to me somewhat >>>contradictory. Either we don't want to have "questions, opinions and >>>doubts there", or it's good "since anyone of us can easily edit it".=20 Now, how about this: > is already on the wiki (can be edited) >=20 > http://www.flamerobin.org/dokuwiki/doku.php?id=3Dwiki:roadmap Didn't I just foresee this? Look at the Roadmap page. You can clearly see my doubt at the bottom of p= age.=20 Nobody has even commented on it yet. It shouldn't be there at all... > Alex could you add it to the news page :) ...so please, Alex, don't put it on the main page. Marius, don't put the = link=20 on main page. Everyone, don't put the link on main page. :) We'll, publish it when it is ready. It is ready when it is defined, and t= here=20 are no more doubts. It can stay in the Wiki, but things like: "For example, I haven=92t got the slightest idea who is going to work on" or "if everyone agrees with this, we need to work out 0.4 - 0.8 in detail." or everything else beneath 1.0.0... should NOT go on the Wiki page!!! Please, Roadmap should be a document, not copy/paste of an e-mail. Marius= , if=20 you wish to speed things up, you should have spoken to Gregory... earlier= , now=20 it seems he's got himself together. I'm sorry to act like this, it may seem harsh, but we need to do things r= ight.=20 For many users, the only place to look for information is the website. So= we=20 cannot allow some half-baked things there. Or, if we do, we should mark t= hem=20 as such: "this is a copy of M.B. e-mail" and not "FR Roadmap" --=20 Milan Babuskov http://abrick.sourceforge.net |
From: Nando D. <na...@de...> - 2005-04-07 07:29:14
|
Milan, most of what I need is already included in your and Michael's lists. Here's the rest I need and want to work on: - sorting out the config and support files path(s). Adding some ability to control (perhaps on the command line) where FR is going to find its config file. - localization. - docs. Things I don't particularly need, yet they'll have to be done before 1.0: - some grant managing tools. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Achim K. <ach...@wi...> - 2005-04-07 08:02:30
|
Hello, perhaps I missed something in this discussion: > - version 0.5, expected end of May 2005 (integration of new DBH object > structure, should facilitate faster development) What is "DBH" ? TIA Achim |
From: Michael H. <mic...@el...> - 2005-04-07 08:27:20
|
Achim Kalwa wrote: > perhaps I missed something in this discussion: > >> - version 0.5, expected end of May 2005 (integration of new DBH >> object structure, should facilitate faster development) > > What is "DBH" ? Database Hierarchy, see http://flamerobin.sourceforge.net/dokuwiki/doku.php?id=wiki:observerpattern Best -- Michael Hieke |