[crossfire] skill window

[Mark Wedel]

On 04/19/10 05:08 PM, Kevin Bulgrien wrote:

> 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.

  For the gtk-v1 client, there was an option for it to create a bunch of top 
level windows, which the player could move about and save their positions, but 
they never really got glued together beyond the player putting them next to each 
other.

  That wouldn't be that hard to do - one could make a half dozen top level 
windows in the glade layout file, and put the different widgets in there instead 
(eg, the map stuff goes into one of those instead of the top level window, the 
info stuff goes in the top level window instead of a container) - I believe some 
extra code would be need to realize them all, as well as load/save positions, 
but that in itself wouldn't be impossible.

  That said, I then do wonder if that is the best way...

>
> 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.

  Certainly there is need for several different options - never meant to imply 
there wasn't.

>
>> - 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.
>

  I'm not really sure what the correct number is, but looking at some of your 
other e-mails, some of the layouts are really the same but for something being 
swapped from one side to another, and that really becomes a preference issue (I 
like my info on left side instead of right) vs a functionality issue (I have a 
small screen and need a layout that works on it.)

  I don't even have much an issue with there being a bunch of layout files 
available and even in SVN (and rpm/packages for that matter).  What I'm more 
concerned about is a clearer indication of what are the 'officially supported' 
(for lack of better term) layouts vs ones that have been contributed and people 
may find useful - it would clearly be good in the client to someone not which 
ones are contrib layouts.

  My main concern would be if something changed requiring an update to all 
layout files, I don't want to have to be updating 20 different layout files.  Or 
for that matter, if a bug is filed against a layout - IIRC, there were/are bugs 
filed regarding formatting in some of the windows, and that will show up based 
on layout decisions in the layout itself.


>> - 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.

  it seems like going to gtkbuilder would eventually happen.  But I'm not 
particularly fond of doing a major rewrite either.

  One thing that might be easier (but still amount of work) is a further 
decoupling of the elements in the window and the window itself.

  For example, right now, there is the dialog.glade file which deals with all 
the pop up windows, so all the layouts don't reproduce that.

  Imagine same thing for most of the other widgets - there is a common file 
which has the declarations for the info widgets, map widgets, etc.

  The the current layout files really just become that - layout files - the 
notebooks, dividers, etc, would be there, and there would be some form of 
placeholder widget to note which widget goes where.

  At run time, the client process that layout file and walks the widget tree, 
finding those placeholder widgets.  When it finds one, it uses information in 
that place holder to know what which widget in common file should get reparented 
to this location.

  In this way, the layout files themselves become very lightweight, and changes 
to any of the main elements just have to get done in that main/common file.

  And since you are already reparenting, it does allow the potential to allow 
user overrides (but how the user would set that up would be much trickier)


>
> 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.

  Yes, that wouldn't be that hard - the client string that is sent is already 
free form, so putting in the name of the layout file wouldn't harm anything.  It 
would require a little work to pull those strings out and tally them up.