From: stephan b. <st...@ei...> - 2003-11-19 16:37:37
|
On Wednesday 19 November 2003 13:26, Rusty Ballinger wrote: > (Just to make sure, in loubetomy, at the bottom of the View menu, you > can turn them on & off, right? You're talking about being able to > toggle them in qub?) Sorry, i wasn't clear - i meant in loub. > Of course you could manually save two different images in loubetomy > (one with them turned on, & one with them turned off)--but one thing > which would probably be easy to add to loubetomy, if you could make > use of it in qub, would be to save the deployment area "layer" > (without terrain) as an image with transparency, which qub could That's exactly what i was thinking. > overlay over the map-with-terrain image when toggled. (If there's a > filename convention you wanted to follow, loubetomy could have an > "export to qub" menu item where you enter some base file name, and it > saves the various "layers" as separate image files.) Or if working > with separate map images would be easier in qub, the "export to qub" > could work that way. File naming doesn't concern me. For s11n i've implemented an input dispatcher which sends streamts to the correct parser depending on the magic cookie and i'll probably add one to QUB as well. (Actually, this uses the classloader, by mapping cookies (instead of class names) to parser factories.) At the moment qub tries to load everything via the gcom loader, and if it can't it tries to load the file as an image (then passes that off to a gcom if it works). This is extremely sloppy, though. > Another thing I thought of tonight which I'd like to add is, I'll do > a neat entry (for water or a castle wall or whatever) in some > palette, but reusing it is kind of hard (you have to edit palette > files by hand, boo, or re-enter the same colors, deviation values, > etc. etc. in the palette entry editor, boo). It would be neat to > have some set of palette entries not attached to any palette, so when > you want to create a new palette entry, you can see a list of > existing entries to choose from as a starting point. That would definately make it simpler. i had a hard time getting started - selecting a map and palette which like each other. BTW: i LOVE what you've done with the Antares map. > (Like a sample > of different water entries, or different forest entries, etc.) > (Although I'm not sure that would work so well for entries which use > game-specific painters which e.g. paint GEV bridges differently > depending on how much damage they've taken, etc.) Wow! i didn't know it could do that! The more i see loub the more i think that it would be a great front-end for qub. :) On Wednesday 19 November 2003 13:45, Rusty Ballinger wrote: > > i thought these were auto-gen'd and removed them. i'll re-add them > > tonights. > > I recently did the same thing in a 'clean' rule in a Makefile I was > writing, too. I'd been goofing with this stuff for a month, had That's exactly what i did - added them to CLEAN_FILES. > Had a good cry. LOL! i had a good panic: "Rusty's gonna kill me!" > Swore to always back up my files, and to never again mix coconut rum > and a command line. Let's see how long you can resist the coconut rum... > (Still not the stupidest way I've ever accidentally deleted files, > though.) i once tried copying qub to a ramdisk to see if i could speed up compilation. i did some changes on the RAM disk and then went to copy them back to my hard drive: rm * ~/cvs/qub/lib/gcom doh! On Wednesday 19 November 2003 14:10, Rusty Ballinger wrote: > > On a related note, i've been considering something > > like the following: > > > > - the core qub and gcoms into one package. > > - Loubetomy, gcommaker, etc. (i.e., all "non-core" utilities) into > > separate CVS modules (one per subproject, or bundle them all, > > doesn't make much difference to me). > > That sounds good to me. Which do you prefer: separate modules per project or one big subproject? i guess that depends on: > > a) each subproject has it's own. > > b) each subproject should be checked out/unzipped to the main build > > tree, and will be picked up from there. > > > > There are of course pros and cons to both approaches. What's your > > suggestion? > > Well, my first impulse is separate builds (at least where there are > no dependencies), just to keep build times down, but that may be a > bit shortsighted. That's precisely the delima i'm in. :/ > ("With pre-compiled headers, there won't *be* any > build times"--that is my claim, although I still haven't actually > tried a version of gcc >3.2, ha ha. 3.3 is supposed to have it?) i'm using 3.3 (comes with suse 9.0) but i haven't looked into this. --help says nothing about it, but maybe it's in the docs. > Let me think about it some. (We won't have to decide until after > 0.8? Or does that depend on how long it takes me to un-break > loubetomy? :) There's absolutely no rush to decide. i certainly haven't settled on one approach or the other yet. i probably won't be ready to put anything into separate tree for at least a couple weeks, in any case. My intention is to get an 0.8.0 build running/installing in the next week, and then release that. i fully expect that there will be a couple 0.8.x releases after that. i haven't given up on the source tree, i'm just considering it as "in maintenance mode". Certainly some of that code will get re-used once i get around to the UI layer for a rewrite. i'd like to look more into QCanvas instead of QWidget, like you've done with loub. Regarding the src tree: i've got another 3-4 hours in the office, and then i'll try to fix up the broken distclean, add missing DIST_FILES, etc. -- ----- st...@ei... - http://www.einsurance.de Student: "Master, you must teach me the way of liberation!" Master: "Tell me who it is that binds you." Student: "No one binds me!" Master: "Then why do you seek liberation?" |