Re: [warzone2100-dev] Release plans
On Thu, May 13, 2010 at 2:20 AM, buginator wrote: > While I haven't personally tested trunk in a long time, Zarel > mentioned that the pathwalking is broken. It is, but there are (too) many patches to fix this problem. This needs to be sorted out, but I do not see this as a long-term problem. > with the new web site style, it isn't exactly > easy to change things, since we rely on one person, and the > information on how to fix/change it, hasn't exactly been forthcoming. The new web page is really nice, but this situation is unacceptable. Easily maintainability must be priority #1. > 1) Qt. ... > While experimenting with Qt Designer for a new lobby screen, I don't > see a easy way to match the current color scheme / "style" of warzone With Qt style sheets? I am not sure why you would want to do that, since it does not give you nearly enough control over how things look. In a game you would typically superclass existing Qt classes to make your custom looking widgets, but where Qt does the record keeping and handling for you. > As of right now, I can only think of one advantage to Qt, and that is > for the hardware colored cursor support. Hardware colored cursor support was just an accidental improvement along the way. The reason for the Qt port is that Qt offers a much richer base to build upon than SDL. This is what it does now: - No more quesoglc and its dependencies - Better fullscreen handling (ok, cybersphinx disagrees on this one) - Better cursors However, what it does now is not the important thing, but what it can do in the future. Right now the things I can think of are: - SVG support, needed for betawidget - signals/slots, for better handling of multi-threading, eg of scripts - improved network code - widget control, can be used for new widget code - general portability (we can dispense with a lot of our custom portability layer in lib/framework since Qt have these things, also for C code) - a nice base for future c++ porting > 4)Beta widget > Yeah, I know this wasn't mentioned, but, it appears there is lots of > confusion of the shape this is in. It uses deprecated lib(s), and > would add lots more dependencies, and trying to compile those > deprecated lib(s) on anything but unix is a huge PITA. > It never really got past the (pre) alpha stage, before it fell by the wayside. > The thinking to revive this was to use Qt for the SVG routines, but, > there have been no tests at all, so we are not even sure if this would > be a good move or not. Everything is "in theory, it should work". The most important part of 'Betawidget' to me is the series of ideas that went into it, which I believe are really good, and in order to get there we need the Qt branch, since the original plan depended on a string of icky library dependencies that was simply not workable. The existing betawidget code can be rebased on top of Qt, or we can rewrite it to utilize more of Qt so we have to do less state maintenance ourselves. > We really need to get feedback about the current trunk builds, so, we > need to start telling people they can download test builds *now*. I agree, but "now" meaning once we have sorted out the path walking problems. > The next biggest problem is, (and I already know there is no easy fix > for this), is that everyone still basically does what they want to. > We are not pooling all our resources/talent into the same pot. I > don't even think this is solvable in a open sourced project. This is not something I would want to "fix". What we should do, though, is to make sure we do not accept new changes without discussion, and for larger changes this discussion should go before the implementation. This is not always easy. The Qt port, for example, started off as a simple experiment and grew by enthusiasm as worries over performance and other potential problems were put to rest. > Heck, the other problem is, I don't even know the status on what > anyone is doing. > One day, a commit will be made, and then you know what that person has > been up to. That would be completely contrary to the commit guidelines and the way things are supposed to work. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Release plans
buginator wrote: > 1) Qt. > The Main menu / in game menus suffer from a state conflict. That is, > when we set modes, (pie_SetRendMode() & pie_SetTranslucencyMode()), it > looks like we are conflicting with the way Qt is handling the > window/widget. Qt suggest to use > beginNativePainting()/endNativePainting(), but that causes a big > performance hit, and didn't really fix anything when I tried some > tests with that. The QPainter in iV_DrawTextRotated is changing the state. Adding a pie_SetRendMode(REND_OPAQUE); call seems to alleviate the issue. Is changing the main menu colors to match the backdrop is intentional? -Safety0ff ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [warzone2100-dev] Release plans
On 5/12/10, Per Inge Mathisen wrote: > 2.3.0 has so far seemed like a pretty solid release, and there is no > desperate need for a 2.3.1 yet. Discussions of new features seem to > have moved to trunk. How about we try to schedule a 2.3.1 bug-fix-only > release for mid-June? We are a bit passed the 'bug-fix only' mantra, since some of the stuff that is currently in svn/2.3 are not really bug fixes per se, but that release schedule sounds OK. > Trunk seems rather stable at the moment, and branching it as a > possible release point before merging any of the big 3 feature > branches may be a good idea. One idea is to branch is to a codename > branch, start merging the feature branches, and depending on how > stable or unstable trunk becomes after that, either proceed to release > from the codename branch, or from trunk after the merges (nuking the > codename branch). While I haven't personally tested trunk in a long time, Zarel mentioned that the pathwalking is broken. Yeah, I know there is a ticket (http://developer.wz2100.net/ticket/1649) but I haven't really had the time to look into this more. The trunk test builds that we threw up haven't really gotten any feedback at all, and with the new web site style, it isn't exactly easy to change things, since we rely on one person, and the information on how to fix/change it, hasn't exactly been forthcoming. > We have 3 big feature branches that we need to merge before > accelerating bitrot makes merging even more difficult. The merge > priority that we have discussed earlier for the big 3 feature branches > is 1) Qt branch, 2) newnet, and 3) lua. Last comes last because it > seems most unfinished yet, and Qt branch first because it has seemed > closest to completion and has the most developers familiar with the > new code. However, we can easily change the merge order - there are no > interdependencies between them. I think we need to clear up some things about these branches. 1) Qt. - we don't really have anyone that is well versed in Qt for the current issues. Those are, on the mac, the input state is swapped from our normal routines. Currently, we can hack around that, however, we still have text issues, and the fact that we can't get key map screen to show Ctrl or Alt like it does on windows / linux for whatever reason. AFAIK, Alt should work like it does on windows / linux, but it doesn't show "Alt +" like it should. The Main menu / in game menus suffer from a state conflict. That is, when we set modes, (pie_SetRendMode() & pie_SetTranslucencyMode()), it looks like we are conflicting with the way Qt is handling the window/widget. Qt suggest to use beginNativePainting()/endNativePainting(), but that causes a big performance hit, and didn't really fix anything when I tried some tests with that. While experimenting with Qt Designer for a new lobby screen, I don't see a easy way to match the current color scheme / "style" of warzone, and if we go this route, the issue then becomes how easy is it to maintain? I have not done any svg tests, so unsure how smooth this will go. As of right now, I can only think of one advantage to Qt, and that is for the hardware colored cursor support. The lack of a dedicated mac & Qt expert person to help us trying to fix this doesn't make things easy, and it gets annoying, since we must waste more time digging into tons of docs hoping to find out the cause, then waiting for feedback. With SDL, we are pretty much at, "it just works" for all the platforms, so people can concentrate on other issues at hand. 2) newnet. Besides the problems listed in http://developer.wz2100.net/ticket/1786, I don't really understand the main reason for having such a high requirement for precision. (I haven't really looked at the code either) Compiler issues are the main problem here, though, I haven't really played with it enough to see if it has other problems. We can't release test builds of this until that is fixed, and we won't merge to trunk, until we know it works as it should. 3) Lua. The last I recall, the state of lua was about 50-55% done, and the forum thread : http://forums.wz2100.net/viewtopic.php?f=35&t=4733 shows that the conversion script is buggy / broken for some things. We don't really have anyone who is a lua expert either (since Gerard was about the closest thing we had, and he isn't around much), so that is slowing things down drastically as well. 4)Beta widget Yeah, I know this wasn't mentioned, but, it appears there is lots of confusion of the shape this is in. It uses deprecated lib(s), and would add lots more dependencies, and trying to compile those deprecated lib(s) on anything but unix is a huge PITA. It never really got past the (pre) alpha stage, before it fell by the wayside. The thinking to revive this was to use Qt for the SVG routines, but, there have been no tests at all, so we are not even sure if this would be a good move or not. Everything is "in theory, it should work".
