Bug - Fixed When logging in, main frame displayed before it is fully created

[Veracity]

Start KoLmafia
The Login Frame appears
Select a character and click the login button
KoLmafia logs me in
-> A little frame appears in the top left corner of where I want my Main Interface to go. I can see the top of a few buttons, but it looks like the frame as a whole is the wrong size.
The Main Interface Frame resizes and is present in its full glory

This started some time last month or so. I could swear I saw somebody else comment on this, too, but my search-fu failed. Of course, Apple gave me a Java update recently, so it could be due to that, rather than hola's recent frame/panel refactoring.

Mac OS X 10.6.8
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)

 

[fronobulax]

I'm seeing something similar on Windows 7. I remember that when it first appeared I was not concerned because it seemed like a side effect of some of Hola's work (dealing with when threads shut down?) that was going on at the time.

 

[wrldwzrd89]

Same deal here. Wonder what's causing it.

 

[fronobulax]

Same deal here. Wonder what's causing it.

Every time I speculate without looking at the code, or searching the forum, I usually end up missing something critical and looking like an idiot. However that seems to be my natural state so...

My recollection is that Hola was tracking down some null pointer exceptions and generally squashing bugs related to the Foxtrot removal. There was a situation where a thread shut down, or a window thought it was unused and the entity disappeared. However something else did depend upon the entity and when it went away the NPE occurred. I recall that the problem and related debugging focused upon what happened between KoLmafia start up and the completion of the login process.

So I figured he rejiggered things so that a barebones window was created at the beginning. It served as a reference and placeholder so that there was a reference and thus the NPEs went away. At some point in the initialization the desktop/main window was built and so it was displayed in all of its glory.

While it was triggered in response to a NPE, this seems to me to have a lot in common with building something that is displayed to the user. Often you create something behind the scene with visibility off and then turn it on only when you are done and ready to reveal your handiwork to the user.

The part of me that thinks I understand this and why it is happening would mark this as Not Going to Fix. However the part of me that shares veracity's pain when there are numerous bug reports because users are confused and concerned does agree that it is better to fix this than it is to explain that it it is not a problem, over and over again.

 

[Veracity]

Often you create something behind the scene with visibility off and then turn it on only when you are done and ready to reveal your handiwork to the user.

This is the key observation: don't turn on visibility until the window is fully constructed, in the right place, and with the correct size.

It used to behave like that. Something changed.

 

[Winterbay]

I think this can be probably said to be universally happening (well or at the very least rather common). Also for what it's worth I get a window with the standard windows buttons (minimize, maximize and close). I've never tried to press the maximize button to see if anything would actually happen.

 

[Bale]

While this behavior may have originated only last month, does it really count as a bug? It doesn't cause any trouble that I have noticed and it is always followed by the window expanding to the proper size.

 

[Veracity]

While this behavior may have originated only last month, does it really count as a bug?

Is it intended behavior? If not, it is a bug.

It doesn't cause any trouble that I have noticed and it is always followed by the window expanding to the proper size.

This would make it a cosmetic or harmless bug.

 

[Bale]

Is it intended behavior?

To know if it was intended behavior, you'd have to be able to read your mind to know what was intended. Are you a mind reader? I'm going to say that keeping the window from appearing before it has assumed its full size should be a "feature request", not a "bug report".

 

[holatuwol]

I have just Adventure and gCLI and I don't observe this behavior.

What are your startup tabs?

 

[Bale]

I have just Adventure and gCLI and I don't observe this behavior.

What are your startup tabs?

I experience this with the following startup tabs: adventure, CLI, Gear changer, Item Manager, Modifier Maximizer, Skill Casting, Purchase (and relay browser, although that does not appear as a tab, but is configured that way).

 

[Winterbay]

I have:
As Tab: Adventue, CLI, Purchases, Gear Changer, Skill Casting
As Window: Mafia Chat

 

[Bale]

You don't have the relay browser as a startup tab? I don't have any startup windows. That means we're down to two troublesome points of commonality after excluding Hola's tabs: Purchase & Gear Changer.

 

[Winterbay]

I generally poke around in the main interface and launch the relay browser when I feel I need it, which isn't every time I log in (especially in aftercore) so I've not seen the need.

Seeing that the default values are "AdventureFrame,CommandDisplayFrame,MallSearchFrame,GearChangeFrame,SkillBuffFrame" and that most people are seeing this I would guess that the culprit is in one of those.

 

[StDoodle]

FWIW, I've had this too, but by the time it registers (with me), KoLmafia has finished loading and is up to normal size, so I never really gave it much thought.

 

[fronobulax]

FWIW, I have

initialDesktop=AdventureFrame,ItemManageFrame,GearChangeFrame,MallSearchFrame,CommandDisplayFrame

.

 

[Veracity]

I have just Adventure and gCLI and I don't observe this behavior.

What are your startup tabs?

I have Adventure, gCLI, Purchases, Skill Casting, Preferences

I just removed the last three, leaving Adventure and gCLI as Startup in Tabs and nothing in Startup in Windows.

I still get the same behavior.

 

[matt.chugg]

I can reproduce this in 10105 : http://kolmafia.us/showthread.php?8...lways-getting-auto-selected-even-when-menu-op
I cannot reproduce this in 10103 : not gui related

Build 10104 wasn't on the daily builds page as it would appear to have been commited shortly before 10105

Hopefully narrowing it down to something in 10104 or 10105 (both of which look GUI related) will help, i'm afraid my knowledge stops here!

EDIT: link wass wrong for 10103, but 10103 wasn't gui related at all so: link to 10104 is: http://kolmafia.us/showthread.php?8...ng-as-a-frame-is-loaded-disable-the-display-T which looks more relevant

 

[fronobulax]

Thanks to matt's work, I am pretty confident that the feature was introduced in 10104. In particular showComponent in KoLDesktop had KoLDesktop.INSTANCE.setVisible( true ); added just before setting the selected index (line 294). When I comment it out the feature goes away and I found nothing broken. I am reluctant to commit that change at the moment because it was apparently introduced to deal with some issues with open windows and logging in and out. I'd really like hola to chime in with why the line needs to be there or veracity to declare that the partial display is a bigger "problem" than what hola was trying to fix.

 

[fronobulax]

r10225. On my system I no longer see the "incomplete" window and I haven't seen anything else that was broken so I am hoping that fixing this has not undone something hola did.