No subject

The problem is, that in a 1028x768 screen (thats the maximum for 17'
monitors) the room
is far to small to do it. If you open the arch panel to a size you need, you
will not see
much from the map windows - and visa verse.

One problem is that we need a really small font in this panel. The normal
font is to big.
But i have not the coding knowledge to put a useful small font in it and
override the normal
one. Every time we tried, some functions (comboboxes, menues) use the old
one.

The final goal is to put all of AVs setting windows in this panel - and make
it possible to
edit in it on the fly.

Fact is that we have the same problem as you. On this stage of coding, you
really should have
same experience about how this all is working. I don't think you can grap
this from books or
examples - you need to have done it before and try out (well, thats whats a
experienced coder
is). And java is on this stage really not trivial.

So, we really need a coder who contribute time and work to migrate the map
arch info in this panel.

Until this, the panel will be "under construction".

Michael

>
     
     
     >
     
      Mark Wedel wrote:
     
     >
     
      >
     
     >
     
      >  One request that I've made before would be for the map windows to be
     
     >
     
      > their own top level windows managed by the OS instead of
     
     >
     
      subpanes within
     
     >
     
      > the editor. Alternatively, if the layout could be a bit different so
     
     >
     
      > that the selected object information on the map was all done in
     
     >
     
      a second
     
     >
     
      > column to the right of the one that is used for selecting stuff to
     
     >
     
      > insert in the map.
     
     >
     
      >
     
     >
     
      >  The odd geometry of my system (3200x1200) means that even if I
     
     >
     
      maximize
     
     >
     
      > the window size of the editor, I effectively lose a lot of editing
     
     >
     
      > space, as the pane for selecte object spans the entire width of the
     
     >
     
      > screen, which isn't very useful.
     
     >
     
     
     >
     
        I actually did some quick hacks, and at least have my first
     
     >
     
      point working
     
     >
     
      (individual top level managed for each map).
     
     >
     
     
     >
     
        I need to hack around some more - the layout of the main window
     
     >
     
      is now less
     
     >
     
      optimal, because the pane area that used to be used for that
     
     >
     
      information is
     
     >
     
      completely unused.  I need to poke around some more and see about
     
     >
     
      moving over
     
     >
     
      the map information to that pane - then I could have a 400x1000
     
     >
     
      (or thereabouts)
     
     >
     
      window for that, and devote the rest of my screen for the map stuff.
     
     >
     
     
     >
     
        The problem with this is I'm not sure how to deal with this as
     
     >
     
      a configuration
     
     >
     
      option.  I'm a pretty java newbie, and the change I basically did
     
     >
     
      was change the
     
     >
     
      map stuff from inheriting from the JinternalFrame to JFrame.  I
     
     >
     
      have no idea how
     
     >
     
        that could get done as a runtime option (maybe inheriting from
     
     >
     
      both, and using
     
     >
     
      the correct constructors depending on the desired behaviour)?
     
     >
     
     
     >
     
        There is also what is perhaps some other behaviour I haven't
     
     >
     
      figured out -
     
     >
     
      using the close (delete) feature of the window manager on these
     
     >
     
      new map panes is
     
     >
     
      ignored - I'm sure there must be some setting someplace to handle
     
     >
     
      what to do on
     
     >
     
      a requested close event.
     
     >
     
     
     >
     
        The close from the editor menu does close the window.  I'm not
     
     >
     
      sure how it
     
     >
     
      figures out which one would get closed - I'm guessing the one
     
     >
     
      last selected.
     
     >
     
     
     >
     
        The easiest solution may be to just include the diffs within the editor
     
     >
     
      distribution and have people just apply the diffs if they want
     
     >
     
      this different
     
     >
     
      behaviour.  I suppose for a 'binary' distribution, both versions
     
     >
     
      could be supplied.
     
     >
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel