gtkradiant/docs/developer/TODO

Things that need to be done in Q3Radiant Linux:

- copy and paste to other instances

Bugs:

- The surface inspector is not updated if you close it,
  select another brush and open it again. (Win32 too)

Win32 version BUGS/TODO list:

- write an XP version of _stat / FileExists in cmdlib
- put the sleep thing in a proper place, bind it in the keyboard shortcuts
- console output bugs: properly format the output, fix "console not scrolling but keeps
  overwriting lines"
    we no longer need to convert to CR/LF to output in the console. removed that.
    interesting piece about the text widget here:
    http://www.gtk.org/tutorial/gtk_tut-14.html
    added freeze and thaw calls in Sys_BeginWait Sys_EndWait
    need to call Sys_BeginWait Sys_EndWait in all appropriate places (Map_LoadFile)
    need to limit size of the console, and scroll down on output
    wrote a test program that reproduces the bug with scrolling
- write a coding directions document (what and where to put stuff)
    qe3.h, globals, map data storage structures
    see DevDocs/draft, need to do something along those lines
- remember maximized state (not only the size)
    and various window position settings
- get rid of the SGIOpenGL flag, (make it default?)
    actually, remove all the prefs crap that's not relevant
- widgets too big?
    at least the menus, or the dialog boxes as well?
- get rid of Texture_LoadTGATexture (or rename it)
    (do l8r)
- sleep mode
- proper about box
- have basic default position and size for the windows in the four views
- plugin API
- have plugin links accessed from plugins menu
- make sure the registry cleaning works
- version information!
- custom shortcut keys file!
    shortcut.ini ?
- problem with strPrefab

- fix user.qe4 thing, don't overwrite. And tell the user about it. Actually allow him to
  select another location / name for the project file.

- command map: changing the file to command.ini? put it in the same dir as radiant.ini
    (get rid of user path

- logging console: add the checkbox
- add the radiant.pid detection!! (this is from 200 -> 201)
- remember window position on the desktop and maximized state
- fix browsing for a directory, the win32 dialog to browse for a dir is fucked
- check creating a new project on linux, I rewrote it and tested on win
- cleanup the q3map code, remove the dirty __TTIMOBUILD stuff

- changes to the jpeg library for the MFC version, must make their way to Gtk
  (proper error handling)

- saving window pos in MainFrame::OnDestroy crashes in 4-view mode (Sagnor)
- 4-view: [00:31] <Sagnor> oh and the "o" for the console doens't work

FIXED: --------
- Printing: Saving screenshot instead
- icon in KDE has "name=quake3": Fixed in the latest setup (thanks Stephane)
- add precompiled headers to speedup building
    done. basically added stdafx.h, the VC5 project needs to be updated
    stdafx.cpp: generate precompiled header with stdafx.h
    all other files: automatic use of precompiled headers...
    (maybe later add more headers to stdafx)
- context switch problems
    seem to have disappeared since I fixed a bug in Str
    no it's definitely back!
    fix by Leo, hacked into gdk.dll for CS_OWNDC window class style
- use proper texture when not found instead of white
    Leo fixed, bug in the custom gluBuild2DMipmaps
- use registry
    for window positions <- Leo did
    have proper default positions!
- bitmap loading broken (can't get anything to load up)
    ok Leo fixed
- renaming some files .. linux_dlgs.cpp to dlgs.cpp etc. let's be neutral!
    done that .. removed linux_*, renamed qgl_linux.c to qgl.c
    (Makefile and VC5 project need updating)
- prefs stuff? big open/close loop on radiant.ini?
    fixed radiant.ini growing huge on win32 (doesn't seem to affect the linux version)
    will have to check with a profiler if that's so bad
- fixed m_strQuake2 (change name and have proper defaults)
    it's the path to the engine we've all been waiting for!
- fixed the new project step
- fixed paklog crashes if /tmp/paklog.txt and the dir tmp doesn't exist on win32
    (ask windows for the temp directory? .. I would put in radiant current dir .. on win32)
    also check on a machine that doesn't define a HOME env var!
- can't reproduce: crash in gluBuild2DMipmaps? seems very random. was not able to reproduce
    it for sure. First time happened on base_trim/pewter.
    happens on image[k++] = *ubptr++; (l1038)
- merge 201 in, use the console logging stuff to debug project settings things

DISCUSSION LOG ABOUT GL SPEED:
[19:17] <Neo|Work> Then why not use your own main, calling g_main_iteration at even intervals? :)
[19:17] <MEGASTeP> shuoldn't be too hard. I hve plenty of code like that
[19:18] *** Joins: Centove (gregm@coco.comstar.net)
[19:18] <Neo|Work> while(1) { while(g_main_iteration(0)) /* do nothing, process until done */; [do own stuff]; pause(); } or so
[19:18] <TTimo> I see .. well actually my main problem is that the GL view is dead slow
[19:19] <TTimo> at first we though it was because of all the stuff between windows and the handlers
[19:19] <TTimo> but the problem seems somwhere else
[19:20] <Neo|Work> can you profile the code?
[19:21] <TTimo> we'll try .. but actually I don't know for sure where the perfomance hit happens
[19:21] <TTimo> might be because it doesn't process the mouse messages quickly enough, or because the refresh messages are sent once every g_main_interaction
[19:22] <TTimo> but compared to the MFC version, it feels sluggish
[19:22] <mordred> yoda: fwiw, it looks like Lance mispaired two sets of speakers when he packed up the Utah offices. If you have no complaints, I'll put my mismatched pair back and take a known pair, which should leave you even. 'k?
[19:22] <Neo|Work> I believe that g_main can block
[19:23] <TTimo> block? what do you mean?
[19:23] <Neo|Work> g_main_iteration(1) blocks if there are no events to process
[19:23] <Neo|Work> might not be at all what's wrong here though. :)
[19:23] <TTimo> you mean it sleeps until more events happen?
[19:23] <Neo|Work> yeahj
[19:24] <TTimo> well that would not be a problem .. the problem is I'd like to emit paint messages faster when the user interacts with the GL window
[19:24] <Neo|Work> I don't know g_main works, but I would assume it uses g_main_iteration(1)
[19:24] <TTimo> ok, well thanks for the insight .. we'll keep looking anyway
[19:24] <Neo|Work> hmm. Your own main look might do the trick, possibly. Dunno. :)