headers
Mark de Wever | 3 Mar 2007 17:53
Picon
Picon
Favicon

making WML error messages more intrusive

At the moment there's quite a lot of UMC which uses deprecated WML and
it doesn't seem to get fixed. I think this might be partly caused by the
fact people don't know things are broken; most people don't look at the
console output Wesnoth generates.

To solve the problem I want to make a new logger, which stores all WML
problems encountered in Wesnoth and adds an extra button on the startup
page. This button named broken WML will show the messages encountered.
If no messages are available the button will be grayed out, if there are
messages the button will be red so it really gets noticed. I _want_ the
button to be intrusive so it does get noticed and not overlooked.

Next to that I think it might be nice if some syntax will be obsoleted
that the message will contain when the support gets removed. After the
support has been removed the message can stay for a while to indicate
when the support has been removed.

Once we find somebody who wants to work on the new campaign server we
can also start to block content which in known to be broken or at least
give an indication that it is broken.

How does this sound?

Mark de Wever aka Mordante/SkeletonCrew
Permalink | Reply | 7 comments |
headers
Richard Kettering | 5 Mar 2007 21:04
Picon

Re: making WML error messages more intrusive

I think it's a really bad idea to clutter up out main page with more  
buttons.

OtOH, I think we can be a lot more draconian, and can get these  
problems solved much faster, if we do one simple thing.  Every time a  
message about deprecated WML gets sent to the console, ALSO throw a  
dialog about it, right up in the user's face.

It'll get stuff fixed in a jiffy.

On Mar 3, 2007, at 10:53 AM, Mark de Wever wrote:

> At the moment there's quite a lot of UMC which uses deprecated WML and
> it doesn't seem to get fixed. I think this might be partly caused  
> by the
> fact people don't know things are broken; most people don't look at  
> the
> console output Wesnoth generates.
>
> To solve the problem I want to make a new logger, which stores all WML
> problems encountered in Wesnoth and adds an extra button on the  
> startup
> page. This button named broken WML will show the messages encountered.
> If no messages are available the button will be grayed out, if  
> there are
> messages the button will be red so it really gets noticed. I _want_  
> the
> button to be intrusive so it does get noticed and not overlooked.
>
> Next to that I think it might be nice if some syntax will be obsoleted
(Continue reading)

Permalink | Reply | 6 comments |
headers
Isaac Clerencia | 6 Mar 2007 11:00
Picon

Wesnothians in the East coast?

Hi, there.

I'm going on holidays to the United States at the end of March.
I'm staying 4 days in Boston and 10 days in New York. I'm not sure if there 
are Wesnoth developers around there, but it would be nice to have a beer 
together :P

See you
--

-- 
Warp Networks | isaac <at> warp.es    | http://warp.es
Debian        | isaac <at> debian.org | http://www.debian.org
Permalink | Reply | 1 comment |
headers
Bruno Wolff III | 6 Mar 2007 13:56
Picon

Re: Wesnothians in the East coast?

On Tue, Mar 06, 2007 at 11:00:02 +0100,
  Isaac Clerencia <isaac <at> warp.es> wrote:
> Hi, there.
> 
> I'm going on holidays to the United States at the end of March.
> I'm staying 4 days in Boston and 10 days in New York. I'm not sure if there 
> are Wesnoth developers around there, but it would be nice to have a beer 
> together :P

That's too far for me (about 900 miles), but if Developers find themselves
in the Milwaukee WI area, I can meet up.
Permalink | Reply | 0 comments |
headers
Mark de Wever | 7 Mar 2007 18:10
Picon
Picon
Favicon

Re: making WML error messages more intrusive

On Mon, Mar 05, 2007 at 02:04:43PM -0600, Richard Kettering wrote:
> I think it's a really bad idea to clutter up out main page with more  
> buttons.
> 
> OtOH, I think we can be a lot more draconian, and can get these  
> problems solved much faster, if we do one simple thing.  Every time a  
> message about deprecated WML gets sent to the console, ALSO throw a  
> dialog about it, right up in the user's face.

I also thought about that solution before but it seemed a bit harsh to
me... but I'm not objecting to that idea and it would indeed keep the
interface cleaner.

> It'll get stuff fixed in a jiffy.

Oh yeah if nobody objects then I'm going for the click away a lot of
dialogs in order to play with broken content.

Mark
Permalink | Reply | 0 comments |
headers
Mark de Wever | 7 Mar 2007 18:17
Picon
Picon
Favicon

Proposal for more changes to the terrain system

This thread contains some ideas to make more changes to the terrain
system.
http://www.wesnoth.org/forum/viewtopic.php?t=15058&start=60

I'd like to hear the opinion from some more developers and artists.

Regards,

Mark de Wever aka Mordante/SkeletonCrew
Permalink | Reply | 0 comments |
headers
Nils Kneuper | 7 Mar 2007 19:25
Picon

just another stringfreeze for the 1.2 branch

Hiho everybody!
Since some big savegame fixes made their way into the 1.2 branch I
wanted to release as soon as possible. First possible date wull be
march, 14th. But that implies that there is a string freeze from now on.
Since noone was working on strings in the 1.2 branch lately I assume
that I can set a string freeze for that branch from now on. If anyone
needs any strings in 1.2.2 to be added/changed, please mail me.
Greets,
Nils Kneuper aka Ivanovic
Permalink | Reply | 0 comments |
headers
Nils Kneuper | 7 Mar 2007 19:31
Picon

Re: making WML error messages more intrusive

Richard Kettering schrieb:
> OtOH, I think we can be a lot more draconian, and can get these
> problems solved much faster, if we do one simple thing.  Every time a
> message about deprecated WML gets sent to the console, ALSO throw a
> dialog about it, right up in the user's face. 
Man, I would love to have a way to inform all users ingame about
anything that is broken in content. Either a really annoying popup box
as long as we are in devel-version and non-rc state and once we are in
rc/stable state I would go for messages that are shown like normal
ingame chatmessage using some "special" color (no idea what could be
used for this). Users of the develversion should know they are testing.
There we can show all that stuff to the users and force them to close
each dialog. Once in a stable state showing the errors in the corner ist
IMO the way to go.
And I think having some way to get a "collection" of all bugs found
shown ingame with some nice stats might be a good thing as extra. Though
showing them ingame should have a higher priority.
Greety,
Nils Kneuper aka Ivanovic
Permalink | Reply | 4 comments |
headers
Nils Kneuper | 7 Mar 2007 19:47
Picon

compatibility and when to remove it

Hi everyone!
We should really start removing WML that is only left for compatibility
to 1.0.x.
In general we should be a little more strict with depricated WML. At
least we should show a depricated message. Within 3 releases after WML
in some area was changed and old one was declared depricated we should
remove this compatibility. That means if WML (like the new terrain WML)
did change in version 1.3.1, we should remove the compatibility to this
old version three (or maybe two) versions later. In this case when doing
it three versions later, version 1.3.4 would not support the single
letter WML anymore. Of course with this all rcs and stable versions just
count as "one" version since we should not change the accepted WML
syntax within these versions.
In general we should be a lot stricter about depricated WML and removing
compatibility layers since they might clutter parts of the sourcecode.
Comments about this?
Greets,
Nils Kneuper aka Ivanovic
Permalink | Reply | 2 comments |
headers
Mark de Wever | 7 Mar 2007 21:09
Picon
Picon
Favicon

Re: compatibility and when to remove it

On Wed, Mar 07, 2007 at 07:47:36PM +0100, Nils Kneuper wrote:
> Hi everyone!
> We should really start removing WML that is only left for compatibility
> to 1.0.x.
> In general we should be a little more strict with depricated WML. At
> least we should show a depricated message. Within 3 releases after WML
> in some area was changed and old one was declared depricated we should
> remove this compatibility. That means if WML (like the new terrain WML)
> did change in version 1.3.1, we should remove the compatibility to this
> old version three (or maybe two) versions later. In this case when doing
> it three versions later, version 1.3.4 would not support the single
> letter WML anymore. Of course with this all rcs and stable versions just
> count as "one" version since we should not change the accepted WML
> syntax within these versions.
> In general we should be a lot stricter about depricated WML and removing
> compatibility layers since they might clutter parts of the sourcecode.
> Comments about this?

One word; agreed!

> Greets,
> Nils Kneuper aka Ivanovic

Mark de Wever aka Mordante/SkeletonCrew
Permalink | Reply | 1 comment |

Gmane