[crossfire] skill window

[Kevin Bulgrien]

>   My fairly random thoughts on all of this:
> 
> - The space used up for the tab for skills & exp is minimal, so for most 
> layouts, the cost of keeping it in place isn't very high.

As for removal, I don't have a problem taking it out of most layouts, and
will likely remove it from most, except for the gtk-v1 layout.  What is less
obvious is how the rest of the layout changes to preserve the intent behind
the original design.

> - Changes where someone else disagrees with that change are always a problem - 
> this can also happen in maps.  In general, if it is the person that originally 
> did the work that disagrees with it, decisions on changes is left to them - 
> however, opinions can be swayed also by what other people say.

Precisely.  And it should be quite clear that input is accepted, and that
.glade tweaks are done for people by request.  meflin.glade and sixforty.glade
are explicitly done to support specific user requests.  To some extent, others
are less obviously designed to a particular user's preference - even the
dialogs.glade has changes inspired by users.

The designer may be the only one who really understands all of why the layout
was made the way it was in some cases.  It only makes sense for the designer
to have more input weight than a user poll.  Whatever the recent flap may
seem to imply, getting feedback and making changes based on them is a high
priority goal.  I do not, however, feel it is appropriate for design changes
to go to a "democratic" vote, and it is clear you feel that way too.

What is not obvious to a third party is that some of the layouts have very
specific reasons for their implementation that may only be noticed under the
conditions the layout was optimized for.  A casual vote on what to change
will likely not appropriately consider the design rationale and preserve it.
It is not always easy to document this rationale, and even less easy to put
it out in a way that would let a voter appropriately decide how to deal with
it.

I am not willing to sacrifice some design goals for a user who does not know
why the design is done the way it is.  In cases such as this, however, I do
feel it is appropriate to allow/support rename and modify to support requests.
In other words, as far as I am concerned there is no flat out "no I won't do
that", but there might very easily be a "you may have what you want, but
perhaps not the way you stated it".  I may want to preserve certain aspects
of certain named designs under that name, but I have no problem copying the
design and naming it something else.

> - In the ideal world, this would be something each user could decide on via 
> setting or the like.  I'm not sure how realistic this is, but I can certainly 
> see why there may be different opinions.  For myself, I have a lot of screen 
> real-estate, so if I want to see that skills and exp, keeping that window up all 
> the time isn't an issue.  But for others, I could see the crossfire game window 
> using up all the screen space they have, so keeping up another window would just 
> hide something else, and having that tab there is handy.
> 
>   At one time, GNOME had the idea of dockable widgets (don't know if it still 
> does), so you could move widgets around, dock them here, there, etc.  If that is 
> still possible, it would basically let users customize the interface however 
> they want (don't want the skills tab?  Just dump it in the trash).
> 
>   A concern I have is that if one has too many options (checkboxes for what 
> stuff to show in the client vs windows), you potentially have a dozen checkboxes 
> down the road of what to show or not show - that isn't great.

For the present, I think the current situation is acceptable.  Those that care
enough about layout can either figure out how to make their own, or ask for
help getting a layout that supports their needs.

While in concept the idea of giving greater flexibility is nice, the level of
work it will take is probably not something worth doing at this point when so
many other things can be done to improve the game.

I do not at all like the idea of having to switch items on and off.  What I
think would be more practical would be to switch to an MDI interface and
allow layout of the MDI to be saved and restored... either that, or figure
out how hard it would be to implement what the gtk-v1 client did where you
could glue windows together and save that state.  Neither of those options
probably require a bunch of configuration controls.

Either way, I think that it is still important to offer options to people
that have 15" or 17", or smaller, monitors...  This was a huge factor in why
it was so hard for me to move to the gtk-v2 layout and is why I did the libglade
rewrite.  I see requests for even smaller displays actively occurring.  Whatever
might be done in the future should not make it difficult for desktop-challenged
users to play.

> - The number of glade files probably needs to be controlled in some way - 
> otherwise,  I could forsee a mass increase here, and the question then becomes 
> who supports them all.
> 
>   One thought is to take 3-4 core glade files and call them the 
> standard/supported ones, and the rest fall into a contrib area.  What that means 
> is that if bugs are filed against the core ones, they should get fixed - if 
> filed against contrib ones, they don't, but whoever contributed that layout file 
> may feel compelled to fix it (or may not) - if a contributed layout gets so out 
> of date it isn't usable, it gets removed.

I think 3-4 is too restrictive, but I agree that the number of officially
distributed files needs to be controlled.  There are currently 12 in the
distribution, and I think that is too many.  Otherwise, in general, I agree
with these statements.

I do think it is important, however to make it clear I do not agree that the
number of .glade files in SVN should be suppressed unnecessarily.  Obviously
we do not want to go crazy with having files that are different only in minor
details, so no argument there about restricting that sort of thing, but, it is
advantageous to allow some designs that have proof-of-concept work in them for
easy access.  I think it should be possible for designers to have a favorite
design in SVN without anyone fussing about it - even if it is not widely used.

Controlling what is officially supported/distributed is as simple as controlling
XML_FILES in gtk-v2/glade/Makefile.am.

> - It would be nice to have a better way of switch layout files, or at least 
> seeing what they are.  Having a .png file of each layout that that is perhaps 
> displayed would be one way.  I would imagine it isn't impossible to have it 
> reconfigure the layout in real-time, but it may require destroying all the 
> widgets and re-creating them (this becomes an issue for images).  My only 
> thought here is that I do wonder how many of those layouts really are used, 
> given that the mechanism for switching does require a restart (I don't know if 
> I'd want to restart my client 12 times to see all the different layouts)

Yes.  libglade can dynamically manage the XML at run-time.  Ideally, it would be
nice.  Practically, I think the UI code needs some work to realize this.  I am
not sure it would not be better to start an effort like that from the ground up
rather than to try to tweak this code base... Maybe as a move to GTK Builder...
That said, I'm not looking to start an effort like that anytime soon.

I think determining client usage might not be that hard.  I think that it would
be pretty easy for the client to register its layout usage with a server.  We
could then use servers like MetalForge or Invidious to get the data without
having to rely on a human poll.

>   Probably got a bit off topic on some of these.

If so, the change is good.

Kevin