[crossfire] [Gridarta-devel] Gridarta concerns [was: IRC traffic for Sunday Oct 22]

[Christian Hujer]

Hi Alex,

On Thursday 02 November 2006 01:17 Alex Schultz wrote:
> (crossposting to the gridarta mailing list)
>
> Christian Hujer wrote:
> > On Tuesday 24 October 2006 15:39 Alex Schultz wrote:
> >
> > <snip>
> >
> >>     -"but I think more importantly, it should be possible to create a
> >> crappy 'my first map' in 10 minutes or less" - Cavehippo
> >
> > At least for daimonin that's possible, and I'd say so it is for
> > crossfire. If you think it's not, please let me know what we can improve.
>
> I haven't looked at gridarta4daimonin yet, however at least in
> gridarta4crossfire, there are few interface issue which I feel affect
> this. The current system of, left click to select, right click to insert
> and middle to delete, is IMHO not the greatest.
I agree.

> It *is* a very fast 
> interface to use, however I personally find it too error prone and also
> could be easier for new users. I personally would advocate an interface
> more like this:
>     -Have a 'tool palette', and allow right, middle and left mouse
> buttons to have separate palette modes assigned to each at once.
In gridarta4daimonin we have this already. It will be merged. I've added this 
to the todo list.
For deletion, it's already possible to configure whether the tool deletes the 
topmost or bottommost object. This is also planned for insertion, but the 
insertion code is so bad that it requires some refactoring first. (Adding 
another boolean to all affected methods would be possible but very ugly)

>     -By default, have left click as select and middle click as insert,
> and right as a new context menu.
Good idea. Should be easy todo once we've merged the UI code. I would want to 
wait with that change until the affected UI code is merged.

>     -Make an easy thing for resetting the tool selections to those
> defaults, possibly a lock option.
Good idea.

>     -The context menu contains actions that can be done to the whole
> stack (i.e. cut, copy, paste, delete, select, insert) and also having
> submenus for each object inside it, for doing similar actions (i.e. cut,
> copy, delete, select) to that object alone.
>     -Key bindings with the following defaults:
>           -Delete key deletes objects (something I wish for regardless
> of if this interface is done or not)
>           -Space bar inserts the selected object on the selected tile
>           -Arrow keys move selection
Good ideas. In Gridarta, nearly full keyboard control is possible. The cursor 
and the selection can be changed using arrow keys. Though, space bar isn't 
for insertion right now but for selection iirc. I'd rather use "i", "ctrl+i" 
and the insert key for insertion.

Maybe we could find a good approach that makes life for GUI users easier as 
well as life for vi users easier (hjkl for movement, i for instert, r for 
replace, x or d for delete, 2+3x for deleting a 2x3 rect ;-)


> This system could be configured to be the same as the existing system,
> or more like what I suggest as a default. IMHO it would make gridarta
> much nicer to use to have such a context menu and to allow mouse button
> configuration and keyboard bindings.
Oh yes.

> I'm not sure how many would agree 
> with me on that, but that's my view on what would be a nicer interface.
Well, I'd selfishly say it's enough that I agree ;-)
Some things you suggest are already there in gridarta4daimonin, some were 
already planned or prepared, and some are good new roundups for that.

> > <snip>
> > * I'm not communicating ideas good enough. Gotta publish more parts of my
> > todo list, also keep information that's already in Daimonin's Mantis in
> > sync with such todo lists.
>
> Speaking of Daimonin's Mantis, is it still in use for gridarta? I was
> under the impression that sf's tracker was considered the primary
> location for new gridarta bugs/etc. I'm not a gridarta developer
> (currently), but I do look at the sf tracker sometimes, and IMHO having
> both in use at once is a pain due to looking at two different places.
> Also, I personally wouldn't exactly be in favor of moving from mixed
> usage to Daimonin's Mantis either for the long term, because when
> viewing it's mixed around all these Daimonin bugs in many views. That's
> just my opinion though :)
The following things need to be kept in mind (pros as well as cons):
* Daimonin has a fairly large user base, also for map makers, and they are 
used to Mantis already.
* Mantis is much more powerful and convenient than the SF bug tracker.
* Mantis currently is bogusly integrated, rendering it useless for people not 
having a Daimonin website account or useless for full automatic processing. 
Semi-automatic processing is possible via CSV export.
* Mantis is faster than the SF bug tracker.
* The SF bug tracker is useless for automatic processing by definition (no CVS 
export, no XML export, no XHTML website)

That said, I fear we have to live with the situation of maintaining 2-3 
parallel issue trackers for a while. As long as the daimonin community sees 
Gridarta as integral part of Daimonin, and they still do and will do so for a 
while, and not as a third party product that's just perfectly made for 
Daimonin, they'll want to use the Mantis bug tracker.

The ideal situation would be that both, SF and Mantis, have a web service 
interface, allow configurable triggers and support asynchronuous messaging. 
That way, all updates to one bug tracker could automatically be copied to the 
other. Alas, neither of them supports just a single of the required features.

From my point of view:
* I see the SF bug tracker as the main bug tracker.
* I have to live with Mantis for Daimonin.
* I'm not a fan of duplicate manual work. I won't copy issue items from either 
bug tracker to another. I would only copy issue items to a new bug tracker if 
that new bug tracker would be better than both, Daimonin Mantis and SF.
* I don't like duplicate bug reports. But: I rather prefer living with 
duplicate reports and duplicate solution entries instead of copying issue 
items and their histories around. For those few duplicates, adding a note 
"this is a duplicate of other bug tracker issue id <foo>" and having 
duplicate work for marking an issue resolved is less work than copying all 
issues.
* I don't care which of the bug trackers you use.
* All that I don't know is whether the crossfire community still wants to use 
the crossfire bugtracker for Java editor bugs. I admit I didn't care about 
this issue myself but relied on Ragnor taking care of that.
* For new issues, I use the SF tracker for neutrality reasons despite the fact 
that Mantis is technically superior.
* I look and maintain reports in both bug trackers.

I could of course (ab)use my "power" and declare the SF tracker as the only 
valid one and force the daimonin community on using the Sf tracker only, but 
I really wouldn't feel good about doing so.


Cher :)
-- 
Christian Hujer
Free software developer
mailto:cher at riedquat.de
http://www.riedquat.de/
PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061103/1bf0f1af/attachment.pgp