Author Topic: (Another) enhancement for compiler interface GUI (+patch)  (Read 15623 times)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: (Another) enhancement for compiler interface GUI (+patch)
« Reply #15 on: February 13, 2006, 04:12:43 pm »
You should now be able to upload .patch files as well.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: (Another) enhancement for compiler interface GUI (+patch)
« Reply #16 on: February 13, 2006, 04:50:47 pm »
First of all: Great it has been accepted. Thanks!

1. you can only clear the list if an item is selected (contra-intuitive)
2. the four buttons are a little too wide now, we may have to play with margins
3. you used a wxMessageBox which you shouldn't
ad 1.)
I actually thought and realised the same, but I thought it's my fault... ;-)
ad 2.)
I tried reducing from 8 to 5 as you suggested and it indeed looks better. I just did a copy&paste, not thinking about cosmetic things.
ad 3.)
The method was initially a copy&paste from OnRemoveLibClick. The one who implemented the wxMessageBox there is to blame... :lol: :lol: :lol:. Anyway: At work I do have a dual-monitor system. But I never realised this issue because I always do the coding on the first (primary) monitor. But interesting to know anyway. Is this something that should be reported to the wxWidgets team?
Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: (Another) enhancement for compiler interface GUI (+patch)
« Reply #17 on: February 13, 2006, 05:17:59 pm »
Quote
Is this something that should be reported to the wxWidgets team?
There is nothing they can do about it, it is due to what wxMessageBox does... it simply calls the MessageBox (or whatever it's called in GTK) function provided by the OS, so the message shows up somewhere. A message dialog on the other hand, has to be shown explicitely, so it can be placed first (AnnoyingDialogs do it automatically).

All other dialogs are (provided you enabled the setting) placed by Code::Blocks before they are shown -- with three notable exceptions:
1. wxProgressDialogs show instantly when they are created, so they show on the wrong display first and are placed correctly on the next vertical refresh (no, don't laugh, seriously!).
2. wxFileDialog and wxDirDialog under Windows don't work properly because Windows is so super smart as to remember the last position where these were opened. Thus, if you open Code::Blocks on the secondary screen, open a file selector, move the main window to the primary screen and open another file selector, it will show on the wrong screen, even though you explicitely placed it differently.
3. A few rare dialogs may actually have slipped through our fingers yet  8)

The actual placement works quite reliably under Windows, but it is really pathetic under GTK. That is mainly because the guy who wrote that code has no clue about GTK or X programming at all...

Maybe someone like Der Meister or Yop could help out? ;)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."