Menu
▾
▴
cadcdev-tiki — Discussion about the Tiki cross-platform toolkit
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(131) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(4) |
Feb
(16) |
Mar
|
Apr
(15) |
May
(18) |
Jun
(25) |
Jul
(13) |
Aug
|
Sep
(3) |
Oct
|
Nov
(7) |
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(11) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Atani <at...@at...> - 2006-02-27 21:30:24
|
On 2/25/2006, "Dan Potter" <ba...@al...> wrote: > >Sounds very cool, though I am pretty much out of console dev these >days, excepting a couple of lingering projects for GOAT. Definitely >keep us posted if it happens! Unfortunately my day job has taken up a lot more of my time lately, but I do have a working PSP toolchain. I have looked at a lot of the PSPDev website and there is a project called PSPGL which is basically eGL (Embedded OpenGL). Most everything is supported that is needed for Tiki. I have yet to do some real testing on the hardware though. Another thing that came up was support for the GP32x which should be pretty simple to do since it is basically a linux handheld, which already supports SDL. OpenGL is done via the TinyGL library, I have not done testing on this yet either though... Mike |
|
From: Sam S. <sam...@gm...> - 2006-02-25 19:55:11
|
On Feb 25, 2006, at 2:49 PM, Dan Potter wrote: > It's now active for all projects. It looks like it'd be sufficient > for what we use it for. I was thinking about importing dcload into > the current KOS/Tiki repo, and then dumping that for import into > SourceForge if we want to proceed down that path. What do you guys > think? Sounds good, it should eliminate the CVS confusion anyway. Do I need to sign up for a SF account? -Sam |
|
From: Dan P. <ba...@al...> - 2006-02-25 19:49:27
|
http://sourceforge.net/docs/E09/ It's now active for all projects. It looks like it'd be sufficient for what we use it for. I was thinking about importing dcload into the current KOS/Tiki repo, and then dumping that for import into SourceForge if we want to proceed down that path. What do you guys think? It doesn't matter too much to me if it stays hosted out of my house, though SF might be a bit easier to use and more reliable in the long run. |
|
From: Dan P. <ba...@al...> - 2006-02-25 19:41:25
|
On Feb 14, 2006, at 6:02 AM, Atani wrote: > Have any of you looked at doing this yet? I looked at the PSPSDK > (opensource) and there appears to be an OpenGL like API available.. > > I have plans to start on a Tiki-PSP port sometime in the near > future for > another game and thought to toss this out there.. Sounds very cool, though I am pretty much out of console dev these days, excepting a couple of lingering projects for GOAT. Definitely keep us posted if it happens! |
|
From: Dan P. <ba...@al...> - 2006-02-19 23:17:47
|
On Feb 19, 2006, at 2:08 PM, Sam Steele wrote: > i changed them from <> to "" to match the rest of the Tiki source. > Cursor / Pointer were originally written from inside TikiBlap, > which used <> to find the headers since it's not part of Tiki. > When I moved them into Tiki, I forgot to make them match the rest > of the source, so while I was adding pch.h to the top, I figured > I'd clean them up a bit too. ~:) *ding ding* Ok, never mind. :) I thought the rest of the source was using <> also. |
|
From: Sam S. <sam...@gm...> - 2006-02-19 22:09:09
|
On Feb 19, 2006, at 5:00 PM, Dan Potter wrote: > Anyway, are those changes from <> to "" needed for Win32? I'd kinda > like to keep the <> if we can. > i changed them from <> to "" to match the rest of the Tiki source. Cursor / Pointer were originally written from inside TikiBlap, which used <> to find the headers since it's not part of Tiki. When I moved them into Tiki, I forgot to make them match the rest of the source, so while I was adding pch.h to the top, I figured I'd clean them up a bit too. -Sam |
|
From: Dan P. <ba...@al...> - 2006-02-19 22:00:28
|
Commits are working again (or should be). Ubuntu package names were a little different :) Begin forwarded message: > Modified: tiki/src/gl/drawables/cursor.cpp (304 => 305)--- tiki/src/ > gl/drawables/cursor.cpp 2006-02-18 16:34:24 UTC (rev 304) +++ tiki/ > src/gl/drawables/cursor.cpp 2006-02-18 16:34:52 UTC (rev 305)@@ > -6,13 +6,12 @@ Copyright (C)2005 Sam Steele */ -#include <Tiki/ > tiki.h> -#include <Tiki/gl.h> -#include <Tiki/hid.h> -#include > <Tiki/drawables/pointerArrow.h> -#include <Tiki/drawables/cursor.h> > +#include "pch.h" -using namespace Tiki;+#include "Tiki/hid.h" > +#include "Tiki/drawables/pointerArrow.h" +#include "Tiki/drawables/ > cursor.h" + using namespace Tiki::GL; using namespace Tiki::Hid; Sorry for the goop there, Apple Mail doesn't seem too good at quoting HTML... Anyway, are those changes from <> to "" needed for Win32? I'd kinda like to keep the <> if we can. I know that in practice it's mainly a stylistic issue these days, but my understanding was that <> should be used for things that are in your include path (e.g. system includes and util libraries) while "" should be used for things that are more "local". Actually I think the semantic difference is that "" is supposed to look in the current dir first, while <> searches include dirs. I guess it could be argued either way there since the Tiki includes are being used from within it, and a design that would require you to use one or the other would suck anyway ;), but they still seem more like shared headers that just haven't been installed yet. I'm ok with it either way really, considering how much I've been working on it lately :) |
|
From: Simon R. <sim...@gm...> - 2006-02-19 21:33:30
|
SSBrbm93IHRoaXMgd2lsbCBvbmx5IG1ha2UgdGhpcyB0aHJlYWQgZXZlbiBtb3JlIG9mZi10b3Bp YyAoSQphcG9sb2dpemUgaW4gYWR2YW5jZSksIGJ1dCBzaW5jZSB0aGVyZSdzIGFscmVhZHkgYW4g SURFIGRpc2N1c3Npb24KZ29pbmcgb24sIGhhcyBhbnlvbmUgZG9uZSBzb21lIEMvQysrIGRldmVs b3BtZW50IHVzaW5nIEVjbGlwc2UgKHdpdGgKdGhlIENEVCBwbHVnaW4pLCBhbmQgaWYgc28sIHlv dXIgb3BpbmlvbnM/IEknbSBpbnZlc3RpZ2F0aW5nIGFib3V0CnVzaW5nIGl0IGluIHNvbWUgcHJv amVjdHMgb2YgbWluZSBidXQgaGF2ZW4ndCBoZWFyZCBtdWNoIGFib3V0IGl0IHlldC4KKFN0aWxs IGxvb2tpbmcgZm9yIGEgZGVjZW50IExpbnV4IElERS4uLiBLRGV2ZWxvcCBhbmQgQW5qdXRhIGFy ZSBhCm1lc3MsIGFuZCBDb2RlOjpCbG9ja3MgaXMgd2F5IG5vdCBtYXR1cmUgZW5vdWdoIG91dHNp ZGUgb2YgV2luZG93cy4pCi0tCi0gU1IK |
|
From: Dan P. <ba...@al...> - 2006-02-19 19:00:23
|
On Feb 19, 2006, at 9:46 AM, Sam Steele wrote: > Mostly it's sluggish, and the tabbed interface is kind of quirky. > I actually hadn't realized how slow the OS X terminal is until I > started coding on win32 again.. i fired up putty to connect to my > linux box and there was noticeably less delay between hitting a key > and seeing the letters. Kinda like GNOME Terminal vs xterm I > guess, eye candy = slower. Yeah... I always appreciated the snappiness of the raw X stuff like Xterm, and I used to use Jordan DeLong's minimalist Golem WM too. I couldn't ever stand the Gnome stuff because it was so slow. Then something snapped in my head and I just didn't care anymore as long as it was less of a PIA to use. :) Which means that compared to both Windows and Linux, OSX is the king for me hands down. I used to have complaints about the snappiness of OSX, but now that I have Tiger and a machine with a sufficient video card, most things seem instantaneous UI-wise. I wish they'd get on with enabling Quartz 2D Extreme. Of course Xcode still just has a crappy UI, so it doesn't get any such excuses. :) The syntax highlighting is bad, the completion is slightly better than VS's defaults, but not as good as VA. There's WAAY too much expectation of mouse interaction still (something which is somewhat true of VS too, but you can at least customize most of it away with macros if nothing else). No way to trace into inlined functions. No auto variables. Horrifyingly bad STL support (true in VS up until 8 anyway, which has *amazing* STL support in the debugger now). Then again Xcode is also free with the OS, while VS costs some huge sum of money unless you get on the gravy train to get it free. I'm embarrassed to say that after all that time of using a good IDE at work, I'm pretty lost with the command line only KOS stuff these days. ;) Not as in "can't figure it out" but "brain just doesn't want to go into gear". > Is VS8 .NET or the one after it? I should see if my college's > MSDNAA site has the latest version before they disable my account > (I haven't attended in over a year, but they haven't gotten around > to deleting the account yet :) ). I'm still working on VS .NET, > which is pretty nice too, especially with the Ankh SVN plugin. VS7.0 was the first ".NET" version. It's kinda dumb, I think the marketing people won the first round and the tech people won the second round. VS7.0 was "Microsoft Visual Studio .NET", and VS7.1 was "Microsoft Visual Studio .NET 2003", but there were more overt references to 7.1. VS8.0 is now just "Microsoft Visual Studio 8" in most places, though the official name is still "Microsoft Visual Studio .NET 2005". It did have a technical point though: VS7 was the first one written with the .NET framework itself. That's one reason it was so slow and had so many UI quirks. It's come a long way in the recent ones. |
|
From: Sam S. <sam...@gm...> - 2006-02-19 17:46:42
|
On Feb 19, 2006, at 12:34 PM, Dan Potter wrote: > That if statement that checks it isn't my syntax, so that must've > been Atani. Maybe it was put there to prevent a null deref when it > checks to see if it's a mouse? Probably best to just let it pass > NULL events straight on down. > Ok, I'll check in my fix for it, then. I removed that if statement at the top, and adjusted the mouse if statements to be if (evt.dev != NULL && ... to prevent the null pointer errors. Now my tiki apps quit when I tell them to! I should have some fun stuff to show off in TikiSquares in a few weeks :) > Yes indeed... there are many things I grudge VS, but its debugger > has no peer currently. I can take a copy of VS8 with Visual Assist > installed and pretty much zen into the code. :) I get more done > with that setup than pretty much any other. I'm not sure exactly > what's wrong with Xcode but it still seems more like a Fisher Price > My First IDE than anything... Mostly it's sluggish, and the tabbed interface is kind of quirky. I actually hadn't realized how slow the OS X terminal is until I started coding on win32 again.. i fired up putty to connect to my linux box and there was noticeably less delay between hitting a key and seeing the letters. Kinda like GNOME Terminal vs xterm I guess, eye candy = slower. Is VS8 .NET or the one after it? I should see if my college's MSDNAA site has the latest version before they disable my account (I haven't attended in over a year, but they haven't gotten around to deleting the account yet :) ). I'm still working on VS .NET, which is pretty nice too, especially with the Ankh SVN plugin. -Sam |
|
From: Dan P. <ba...@al...> - 2006-02-19 17:34:45
|
On Feb 18, 2006, at 1:04 PM, Sam Steele wrote: > The quit message is sent with dev = NULL, which means GenMenu's > processHidEvent wont pass it along to inputEvent(). Should we add > a "window system" device, or just let NULL devices pass into > inputEvent()? That if statement that checks it isn't my syntax, so that must've been Atani. Maybe it was put there to prevent a null deref when it checks to see if it's a mouse? Probably best to just let it pass NULL events straight on down. > Btw, this was much easier to debug in Visual Studio than XCode.. > Apple should work on that :-P Yes indeed... there are many things I grudge VS, but its debugger has no peer currently. I can take a copy of VS8 with Visual Assist installed and pretty much zen into the code. :) I get more done with that setup than pretty much any other. I'm not sure exactly what's wrong with Xcode but it still seems more like a Fisher Price My First IDE than anything... |
|
From: Sam S. <sam...@gm...> - 2006-02-18 21:04:16
|
On Feb 18, 2006, at 3:17 PM, Dan Potter wrote: > I dunno if you're doing this or not, but when the user closes the > window, it's supposed to submit a HID message requesting that you > quit. It then waits for the thread to quit. So if the quit message > is being lost or not responded to properly, that might do it. > The quit message is sent with dev = NULL, which means GenMenu's processHidEvent wont pass it along to inputEvent(). Should we add a "window system" device, or just let NULL devices pass into inputEvent()? Btw, this was much easier to debug in Visual Studio than XCode.. Apple should work on that :-P -Sam |
|
From: Dan P. <ba...@al...> - 2006-02-18 20:17:50
|
On Feb 18, 2006, at 10:52 AM, Sam Steele wrote: > I see the SVN commit notifications aren't working again .. I > committed mouse support for win32. I had to add two files to the > win32 solution, and I had adjusted the search path for OpenAL in my > project file before that to c:\openal\include, so you might need to > change that back if you update. Doh... I'll look at the server and see if I can figure it out. > I'm still having problems w/ the win32 tiki app quitting. The app > doesn't quit when my gamethread terminates, and my gamethread wont > terminate when I close the window. Is there something I'm > forgetting to do? I dunno if you're doing this or not, but when the user closes the window, it's supposed to submit a HID message requesting that you quit. It then waits for the thread to quit. So if the quit message is being lost or not responded to properly, that might do it. At least that's my memory of how it works on OSX, maybe the Win32 one was different. |
|
From: Sam S. <sam...@gm...> - 2006-02-18 18:52:26
|
I see the SVN commit notifications aren't working again .. I committed mouse support for win32. I had to add two files to the win32 solution, and I had adjusted the search path for OpenAL in my project file before that to c:\openal\include, so you might need to change that back if you update. I'm still having problems w/ the win32 tiki app quitting. The app doesn't quit when my gamethread terminates, and my gamethread wont terminate when I close the window. Is there something I'm forgetting to do? -Sam |
|
From: Atani <at...@at...> - 2006-02-14 21:20:35
|
Have any of you looked at doing this yet? I looked at the PSPSDK (opensource) and there appears to be an OpenGL like API available.. I have plans to start on a Tiki-PSP port sometime in the near future for another game and thought to toss this out there.. Mike |
|
From: atani <at...@at...> - 2006-01-01 20:03:08
|
On Jan 1, 2006, at 11:28 AM, Dan Potter wrote: > On Jan 1, 2006, at 10:52 AM, cadcdev-svn- > co...@li... wrote: > >> Making m_txr protected vs private so Texture can be extended and >> m_txr accessed. > > Speaking of this, am I the only one who wished they'd put an > access_cast in C++? I think the protected/private stuff is a good > guideline to follow (and when it Very true. Having a way to get at the "private" methods would be cool... I am not sure how best to implement this and ensure that things are still protected properly from tampering.. In this case I just wanted to be able to extend the Texture class so I can have BZ2Texture which is basically a raw KMG that has been bzip'd. This resulted in a smaller file than with png/jpg compression. In Tiki, I think I already pushed this change out, if not I will get it pushed out shortly. I am thinking of adding a RawTexture class which you define the raw texture data which should be uploaded directly to opengl, think of this as a way to handle generated texture data that does not change. Mike |
|
From: Dan P. <ba...@al...> - 2006-01-01 19:28:13
|
On Jan 1, 2006, at 10:52 AM, cadcdev-svn- co...@li... wrote: > Making m_txr protected vs private so Texture can be extended and > m_txr accessed. Speaking of this, am I the only one who wished they'd put an access_cast in C++? I think the protected/private stuff is a good guideline to follow (and when it really needs to be changed, like the above, it should change), but sometimes you just need to be naughty and you know it and don't care. :) For example at work I was trying to augment the stupid MS STL iostream classes to allow 64-bit file pointers, but it turned out that the only way I could get at the underlying file descriptor reliably was to modify their STL code. I couldn't even use offsetof() to cheat. I would've had to make a copy of half their STL library and modify that one class to have public instead of private, even to do that. >_< |
|
From: atani <at...@at...> - 2006-01-01 18:41:43
|
I am not sure of the best way to solve this, but... Perhaps extend the Drawable for your menu bar to have a bool value which denotes remove anims. This can be done in the draw() method, resetting the bool to false. Mike On Jan 1, 2006, at 10:22 AM, Sam Steele wrote: > Ran into an interesting situation. Right now I'm using the > LogXYMover anim to move the selection bar around on my menu. When > the user presses a direction on the d-pad, I call animRemoveAll in > case the bar is already moving, and then add a new LogXYMover with > the correct coordinates. The issue I'm running into is that > because the app is threaded, there's the possibility of the user > hitting the d-pad in the middle of the anim list getting > enumerated, causing: > > *** ASSERTION FAILURE *** > Assertion "m_inlist" failed at ../include/Tiki/list.h:46 in `getNext' > > when the list suddenly disappears in the middle. Is there a better > way I should handle the animations? > > -Sam |
|
From: Sam S. <sam...@gm...> - 2006-01-01 18:21:50
|
Ran into an interesting situation. Right now I'm using the LogXYMover anim to move the selection bar around on my menu. When the user presses a direction on the d-pad, I call animRemoveAll in case the bar is already moving, and then add a new LogXYMover with the correct coordinates. The issue I'm running into is that because the app is threaded, there's the possibility of the user hitting the d-pad in the middle of the anim list getting enumerated, causing: *** ASSERTION FAILURE *** Assertion "m_inlist" failed at ../include/Tiki/list.h:46 in `getNext' when the list suddenly disappears in the middle. Is there a better way I should handle the animations? -Sam |
|
From: Sam S. <sam...@gm...> - 2005-12-23 23:53:08
|
Should be easy enough to rip out the ball, paddle, goal, and border drawables from TikiBlap and have them use pre-defined vertices instead of loading them from a file -- the only issue is that I'm using the sg module from plib for collisions, though I suppose it's not -that- hard to do bounding-box collisions myself. I'll look into doing it this weekend. I should really drop plib anyway now that I'm using Tiki. the sg module made sense when I was also using the fnt module, but now it's just an unnecessary dependancy. -Sam On Dec 23, 2005, at 4:30 PM, atani wrote: > > Would you consider writing a Tiki example app showing how to do a > pong style game? > > I am thinking of trying to port over a few of their other samples > (particle engine one specifically) to Tiki and checking them into > the examples tree. > > Mike > > On Dec 23, 2005, at 12:10 PM, Sam Steele wrote: > >> But TikiBlap is way cooler than the 3D pong demo on their >> screenshots page :-P Though, it does look like it has better >> lighting. >> >> -Sam >> >> >> On 12/23/05, Sam Steele <sam...@gm...> wrote: >> It's got full-screen support! :-D >> >> -Sam >> >> >> On 12/23/05, atani <at...@at... > wrote: >> >> While reading freshmeat.net a couple days ago I found the GLFW >> project, http://glfw.sourceforge.net/ They have a few ideas similar >> to what we are doing with Tiki. I am thinking of taking their >> network abstraction packages as a basis for implementing a >> Tiki::Network package. >> >> What do you guys think? >> >> Mike >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep through >> log files >> for problems? Stop! Download the new AJAX search engine that makes >> searching your log files as easy as surfing the web. DOWNLOAD >> SPLUNK! >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click >> _______________________________________________ >> cadcdev-tiki mailing list >> cad...@li... >> https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki >> >> > |
|
From: atani <at...@at...> - 2005-12-23 21:30:22
|
Would you consider writing a Tiki example app showing how to do a pong style game? I am thinking of trying to port over a few of their other samples (particle engine one specifically) to Tiki and checking them into the examples tree. Mike On Dec 23, 2005, at 12:10 PM, Sam Steele wrote: > But TikiBlap is way cooler than the 3D pong demo on their > screenshots page :-P Though, it does look like it has better > lighting. > > -Sam > > > On 12/23/05, Sam Steele <sam...@gm...> wrote: > It's got full-screen support! :-D > > -Sam > > > On 12/23/05, atani <at...@at... > wrote: > > While reading freshmeat.net a couple days ago I found the GLFW > project, http://glfw.sourceforge.net/ They have a few ideas similar > to what we are doing with Tiki. I am thinking of taking their > network abstraction packages as a basis for implementing a > Tiki::Network package. > > What do you guys think? > > Mike > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > > |
|
From: Sam S. <sam...@gm...> - 2005-12-23 20:17:07
|
But TikiBlap is way cooler than the 3D pong demo on their screenshots page :-P Though, it does look like it has better lighting. -Sam On 12/23/05, Sam Steele <sam...@gm...> wrote: > > It's got full-screen support! :-D > > -Sam > > > On 12/23/05, atani <at...@at...> wrote: > > > > > > While reading freshmeat.net a couple days ago I found the GLFW > > project, http://glfw.sourceforge.net/ They have a few ideas similar > > to what we are doing with Tiki. I am thinking of taking their > > network abstraction packages as a basis for implementing a > > Tiki::Network package. > > > > What do you guys think? > > > > Mike > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > > _______________________________________________ > > cadcdev-tiki mailing list > > cad...@li... > > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > > > > |
|
From: Sam S. <sam...@gm...> - 2005-12-23 20:06:08
|
It's got full-screen support! :-D -Sam On 12/23/05, atani <at...@at...> wrote: > > > While reading freshmeat.net a couple days ago I found the GLFW > project, http://glfw.sourceforge.net/ They have a few ideas similar > to what we are doing with Tiki. I am thinking of taking their > network abstraction packages as a basis for implementing a > Tiki::Network package. > > What do you guys think? > > Mike > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
|
From: atani <at...@at...> - 2005-12-23 20:03:23
|
While reading freshmeat.net a couple days ago I found the GLFW project, http://glfw.sourceforge.net/ They have a few ideas similar to what we are doing with Tiki. I am thinking of taking their network abstraction packages as a basis for implementing a Tiki::Network package. What do you guys think? Mike |
|
From: atani <at...@at...> - 2005-12-23 19:48:20
|
If you are lucky the SVN plugin will work for you better than it did for me... If you have the raw SVN client installed it should work fine.... I have that, and then I installed the SVN explorer plugin (tortise sp) and things seem to crash now on startup with the SVN plugin enabled. My attempts to recompile the SVN plugin from the sources have been not successful but it appears that there might have been a bugfix in the sources which are not included in the binaries from their website. Mike On Dec 23, 2005, at 8:48 AM, Sam Steele wrote: > Hmm.. I browsed the site pretty quickly -- doesn't look like it has > a RAD plugin for MFC, but it does have one for wxWidgets. > Considering I have to redistribute MFC with my apps anyway, maybe I > should look into using wxWidgets instead, though I haven't really > been too impressed by wxWidgets-based apps on linux.. maybe it's > better on Windows. I'll have to try it out this weekend I guess. > I wonder how hard it would be to add a wxWidgets GUI to a Tiki app > -- I'm only really familiar with Cocoa, and I know a little bit of > MFC and GTK+. > > Btw, have you tried out the SVN plugin? > > -Sam > > > On 12/23/05, atani <at...@at...> wrote: > > Its a cheap alternative to MSVC... And it works with the VC .NET 2003 > free compiler too! > > I have been using it for about a week now on windows (fighting with > getting Tiki to compile cleanly in it, downloading dependencies, > etc). I have it compiled and mostly usable on linux as well, but I > think it is fubar'd on my linux build. > > Mike > > > On Dec 22, 2005, at 6:44 PM, Sam Steele wrote: > > > I've been hearing a lot about Code::Blocks lately. Is it any good? > > > > -Sam > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > cadcdev-tiki mailing list > cad...@li... > https://lists.sourceforge.net/lists/listinfo/cadcdev-tiki > |
2 messages has been excluded from this view by a project administrator.
