Itches, Glitches & Anything Else...

[OrbWeaver 679]

You would have to add the icon to each ToolItem individually - look at the "Draw AABB" toggle in radiant/ui/modelselector/ModelSelector.cpp which uses this method (however I have never used UIManager in anger so I cannot be totally sure the same technique will work).

[greebo 103]

Ok, I just wanted to try it out, but it seems the new brushexport plugin is not compiling:

 

gplusplus -Wl,--kill-at -shared -o build\debug\brushexport.dll build\debug\contrib\brushexport\plugin.os -Lbuild\debug\libs -Llibs -llibxml2 -lz -liconv -lglew32 -lglu32 -lopengl32 -lgdi32 -lglib-2.0 -lgobject-2.0 -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lpango-1.0 -lpangowin32-1.0 -lgdk_pixbuf-2.0 -Wl,--output-def,build\debug\brushexport.def
c:\programme\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibxml2
collect2: ld returned 1 exit status
scons: *** [build\debug\brushexport.dll] Error 1
scons: building terminated because of errors.

 

I tried to use "brushexport_env.useXML2()", but that didn't help. Is this just me?

[OrbWeaver 679]

brushexport_lib = brushexport_env.SharedLibrary(target='brushexport', source=brushexport_lst, LIBPATH='libs')

 

Try removing the LIBPATH='libs' argument, it will be overriding any LIBPATH values that are added previously.

 

Merging this plugin was a temporary fix for the inability to export to OBJ, eventually I would like this to be part of the main program as with DoomEdit.

[greebo 103]

Yes that did work, thanks! I'll look into the icon thing in the evening, have to leave now (plasma pysics lecture)...

[greebo 103]

Man, is there a way to make DarkRadiant linking any faster? It takes ages to link up the exe, I would be a lot faster if changing a single line would not entail three to four minutes of waiting.

[OrbWeaver 679]

Man, is there a way to make DarkRadiant linking any faster?

 

Use Linux.

 

5 - 10 seconds for a final link.

[greebo 103]

My goodness, I will try this, I tell you. I have a shiny ubuntu 6.06 i386 ISO lying on my table for exactly this very moment, now I just need to find another hard drive to throw it on (this one is too small for a dual-boot, I'm afraid.)

[sparhawk 17]

Don't be afraid. Linux is quite nice to use, depending on the task.

[OrbWeaver 679]

Absolutely. It knocks the spots of Windows for everything except...well, running Windows programs.

[greebo 103]

I'm not afraid . There was just no real excuse for me to switch over (till now). I know that Linux is powerful and I planned to try it out (more than just inserting a Live-CD) several times, but I always postponed this as I will certainly need some time to get everything set up the way I want it to be - I've always been too lazy/busy, but I'm still planning to switch over completely some day.

[ascottk 0]

I've had the best luck with Fedora Core Linux. The apt-get function borrowed from Debian really makes this distro painless to upgrade.

[greebo 103]

I'm somehow feeling where this thread is leading to... I think I will be able to choose my distro myself.

 

Concerning the toolbar icons: it looks like there is light at the end of the tunnel; it seemed that I forgot to call a gtk_widget_show on the added icon, which is strange, because in ModelPreview.cpp there is not a single call to gtk_widget_show() whatsoever and it's obviously working without problems.

[NeonsStyle 597]

Hey all,

 

Wondering if you guys can fix that texture smudging crash problem? With no autosave, its really bugging me when it goes into that texture smear, and crashes. There's no way to predict when it does it. Its annoying when you spend time fixing up soemthing on the map, only to lose it. Everytime it smears, it crashes.

 

[EDIT] Oh, I just found autosave does work. It just saves it in snapshot rather than as autosave.map... goodie, I got my work back

 

Venus

[greebo 103]

Hm, the autosave is working for me, I just checked. Can you provide a sample map with exact steps to reproduce the problem? Does this also occur on newly created maps?

 

edit: Just saw your edit. What the heck is snapshot? My file is named bonehoard.autosave.map, in the map folder.

[NeonsStyle 597]

Hm, the autosave is working for me, I just checked. Can you provide a sample map with exact steps to reproduce the problem? Does this also occur on newly created maps?

 

edit: Just saw your edit. What the heck is snapshot? My file is named bonehoard.autosave.map, in the map folder.

 

well as I said earlier about autosave; when I first created my map, it saved an mapname.autosave.map, but after that it was never updated again. Then I changed my mapname, and an autosave has never been created for it. However, in the maps\snapshot folder, I have many snapshots entitled 'rivertown.1.00.map - 2.11.map).

 

As for the texture problem. When you use the surface editor or the ctrl-arrow nudge, and the texture smears like it does sometimes, it will crash immediately every time.

 

As for providing a map, sure just tell me exactly what you want. I don't know how to reproduce the autosave problem... it just doesn't do it... as for texture, just hit ctrl-arrow till the texture smears. It should crash.

 

Venus

[OrbWeaver 679]

Concerning the toolbar icons: it looks like there is light at the end of the tunnel; it seemed that I forgot to call a gtk_widget_show on the added icon, which is strange, because in ModelPreview.cpp there is not a single call to gtk_widget_show() whatsoever and it's obviously working without problems.

 

If you call gtk_widget_show_all() on a top-level widget it will automatically show any subwidgets. This is how I make dialog components visible, hence the lack of individual gtk_widget_show() calls - you may be able to do a show_all() on the toolbar itself which should make all of the icons visible provided they are parented first.

[greebo 103]

If you call gtk_widget_show_all() on a top-level widget it will automatically show any subwidgets. This is how I make dialog components visible, hence the lack of individual gtk_widget_show() calls - you may be able to do a show_all() on the toolbar itself which should make all of the icons visible provided they are parented first.

Thanks, I found that one immediately after posting, as I thought there has to be a way around showing every single widget you create. At the moment I'm not progressing much, as my breaks are so short that I can compile just once or twice while eating till I have to leave home again.

[greebo 103]

Ok, I was so close... all the code for loading the toolbar with GtkUIManager, assigning the actions and the right icons was done - and then I realised that GtkUIManager doesn't support ToggleButtons.

 

At least I could not find anything on this topic anywhere on the net. Yuck.

 

If it wasn't for the ToggleButtons, the solution using GtkUIManager would've been really smooth and elegant (just load the actions and connect them to the existing functions, then assign the icons), but there is no clean way to integrate the ToggleButton callbacks, except for a dirty workaround that would make the use of GtkUIManager pointless in the first place. (No wonder there is so little documentation on the use of GtkUIManager - it seems no one is using it).

 

So I'm afraid I will fall back to my first plan to write an own XML parser for the toolbars that can handle both ToolButtons and ToggleToolButtons.

[OrbWeaver 679]

Wow, that sucks. It seemed like UIManager was perfect for the job based on its description, although looking at the PyGTK tutorial which refers to ItemFactory (the predecessor of UIManager) there is a warning note "ItemFactory does not support images in menus", so maybe it is indeed not as functional as it first appears.

[greebo 103]

Yes, this GtkUIManager implementation seems rather incomplete in regard to what GTK+ is usually capable of. And there is nearly no documentation or example code on the net (except for the specs on gnome.org and the Python thing), which transforms coding into a series of trial & error.

 

I'm writing my own XML parser now, it's easier anyway. :-) I hope that I can finish this till the weekend.

[OrbWeaver 679]

I'm writing my own XML parser now, it's easier anyway. :-) I hope that I can finish this till the weekend.

 

Not from scratch I hope - the xmlutil library is available for this purpose.

[greebo 103]

No, not from scratch :-). I will probably just add two functions to the existing xmlutil/Node.cpp, and the rest should be straight-forward.

[greebo 103]

Okay, it is straight-forward right to the point where these callbacks are involved. The one who constructed this maze of callbacks and callers must've been either a genius or on drugs (or both).

 

I found that the radiant code for toggleButtons uses deprecated GTK-functions, and I somehow did not manage to re-use them (GTK tells me that it is not possible to mix deprecated and non-deprecated functions).

 

So I've been wading through all those typedefs and templates and classes that all seem to call themselves for over an hour now and it's still not quite clear to me. My goodness, two weeks of C++ and now this...

 

For the moment I'm stuck at this point: the toolbar is displayed and all the buttons are functioning, but the toggle buttons don't work as expected (it is possible to toggle mulitple buttons at a time, but it shouldn't).

[OrbWeaver 679]

The problem is that you are rewriting something which is already entwined with legacy Radiant code, rather than adding an entirely new feature which does not require any interaction with the Radiant Template Crap .

 

You can always take an SVN diff of your changes, archive it and then work on something more localised if the rewrite seems to be getting too complex.

[greebo 103]

Heh, I finally found a way to integrate my new toggle buttons with the existing callbacks, so the toolbar is fully working now.

 

Next steps are testing, documenting the changes and stripping the unused code. This won't take too long, so hopefully I can commit something this evening or tomorrow.