On Thu, May 13, 2010 at 2:20 AM, buginator buginato...@gmail.com 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
