xuni: a Graphical User Interface Widget Toolkit

I've finally uploaded a reasonably recent version of xuni, my latest project. It's a GUI (Graphical User Interface) "library" (Widget Toolkit) for the SDL, written in C. (I hope to make it a library eventually, but right now it's just a program . . . .)

Here it is: http://dwks.theprogrammingsite.com/m...wn/xuni.tar.gz
Here's a screenshot (subject to change): http://dwks.theprogrammingsite.com/m...n/xunishot.jpg

This is a very preliminary upload. It's the subversion version 73. There is no Windows executable, though there are 32-bit and 64-bit Linux executables. It's not even the absolute latest version, just the latest commit. Anyway, it should run under any platform, assuming you felt like downloading SDL, SDL_image, SDL_ttf, and SDL_gfx in order to compile it. ;) I'll probably have a Win32 executable uploaded pretty soon. Meantime, Windows users can admire my screenshot. :) It doesn't do the parallax justice.

Textboxes and listboxes don't work very well, but buttons and (I think) checkboxes do. (Actually, checkboxes work in the latest version, but not this one. Too bad. You'll have to wait for the upgrade. :p ) You can press ALT-ENTER to toggle fullscreen, ALT-F9 to minimize the window, and different keys instead of clicking on buttons. For example, 'q' quits, at the main menu. I'm in the middle of dealing with themes, so there's lots of code that looks like it's doing things in a stupid way at the moment.

Other than that, xuni is pretty neat. It supports arbitrary screen modes, rescaling widgets and images and text to fit the new size. Its GUI data is in XML files (read via expat), so you can change the positions of the buttons etc without recompiling the program. (Have fun . . . positions are specified as percentages of the screen, i.e. 50 is halfway across the screen.) It has a really primitive "garbage collector", which is really just a reference counter. But at least it does catch some memory leaks, which you'll see if you run the program from the command line. xuni has a very simple expression parser, so you can even use 100/3 instead of 33.3333... in the XML resource files.

It's about 7,000 lines long, which is pretty large for one of my projects. Most of the code is well separated into different source files -- except for graphics.c! -- and nearly all of it is quite well modularized. (I didn't write resize.c, which is SDL_Resize; and it's actually not even used in this version.)

Anyway, have a look at xuni if you feel like it and tell me what you think. Feedback would be much appreciated . . . .

For example: is struct widget_t in graphics.h too unwieldy? Would a void* pointer be better? etc. . . .

I know I put my codeform thread in General Discussions, but I figured that this is a better place for this type of thread. Hopefully it will get some traffic in this forgotten corner of CBoard . . . .

I've updated the web page for xuni. It no longer has broken links and x's where I was supposed to fill information in before uploading it.

http://dwks.theprogrammingsite.com/myprogs/xuni.htm

> I've updated the web page for xuni. It no longer has broken links and x's where I was supposed to fill information in before uploading it.

LIES! http://dwks.theprogrammingsite.com/m...xuni-xx.tar.gz gives a 404.

Oops . . . I forgot to get rid of that "-xx" after all. Oh well. I just fixed the page again.

Alright, I've uploaded xuni again. It's SVN version 79 this time, up from 73. It's very different. There's a very, very basic resource editor (./xuni) that doesn't even let you save, plus the old test program renamed to ./test -- although the old test program has been changed significantly. You can type a different theme name and that is actually loaded (try "shadow" and "alienglow round" and "bluesq"). You can type a new font name, and it is actually loaded (try "gui/PenguinAttack.ttf"). NASA images make the artwork look so much better. There are some bugs with it (click on the options->graphics menu, on nothing in particular), but it's pretty good.

I apologise that only a Linux 64-bit executable is uploaded at the moment. I'm going to get other versions as soon as possible.

Direct link for the latest version: http://dwks.theprogrammingsite.com/m...xuni-79.tar.gz

There -- I've created 32-bit Linux executables and Win32 executables for xuni SVN version 79. They are available at:

• Linux 32-bit executables: http://dwks.theprogrammingsite.com/m...ux-i386.tar.gz
• Win32 executable*: http://dwks.theprogrammingsite.com/m...9-win32.tar.gz
• With either of the above archives, you'll still need to download the main archive at: http://dwks.theprogrammingsite.com/m...xuni-79.tar.gz
  Just copy the contents of the lin32 or win32 archive into the root of the other archive, and run test-i386 or xuni.exe (which is really ./test, not ./xuni) instead of ./test (which is the 64-bit Linux version).

* Note: this archive only contains ./test, not ./xuni -- but ./xuni is only the very rudimentary alpha version of the resource editor, and not very interesting at the moment. This archive also contains all -- that I know of -- of the DLLs required to run xuni. So now, Windows users, try it out, because you shouldn't have to download anything else . . . besides the other archive, of course.

In case I got the links wrong, you can access all of these files from xuni's web page at: http://dwks.theprogrammingsite.com/myprogs/xuni.htm

Also note that while I tested the 32-bit executable quite thoroughly, the Windows one was only tested (and even compiled!) under wine. You'll have to let me know whether it works or not under a native Windows environment.

EDIT: the project seems pretty cool, I may want to join the project, but my C skills are lame so we will see.

EDIT2: Ran it from the CLI since I noticed that it does some output, finding all sorts of stuff now, attempting to consistently reproduce the error messages. Most have to do with attempting to deallocate null pointers, or freeing duplicate strings (is what the error messages say at least)

EDIT3: First bug report sucked because I didn't test it very well, it seems if you click anywhere but the buttons on the graphics options page you get full screen/windowed toggle.

Well, I'm glad you're interested in it . . . .

I'm sorry I haven't been updating this page more frequently; I thought no one was interested. ;) I have in fact fixed all the memory leaks that are reported by the internal garbage collector at the moment. And I'm aware of the click-on-options-graphics-panel-to-toggle-fullscreen bug. In case you're interested, it's caused by this:

In a likely misguided attempt to prematurely optimise how widgets are addressed, widgets are first loaded by name such as "options graphics/fullscreen", for example. Then, an enum value such as WID_GRAPHICS_FULLSCREEN (in options.c) is assigned to the widget matching this name. Finally, a pointer to the actual widget is found, and all of this information is stored in a widget_nameid_t. Then the widgets can be referenced by the enum values instead of by strings, which is presumably more efficient.

Anyway. The trouble is that each panel has its own array of widget_nameid_t's. This is to let different menus etc use their own enum values starting from zero -- otherwise, each enum value would have to be unique, and that would be annoying. But when a widget is clicked in, the enum value is returned; and yet, options.c has no way of telling whether the panel was clicked or the fullscreen checkbox was clicked, because both happen to share the same wids. (Widget IDentifiers.)

I should be able to fix this pretty soon -- the most plausible way to do it is to check all wids in options_perform_click() from the root element to the clicked element. That is, for the fullscreen checkbox, check for PANEL_OPTIONS_GRAPHICS and then WID_GRAPHICS_FULLSCREEN.

BTW, the latest version also has very nice textbox support and theme roundness . . . sorry I can't upload it at the moment, but I shall try to do so as soon as possible. Probably tomorrow by the very latest. The trouble is that I'm working on it for several hours every day, so even yesterday's version is going to be quite different from today's . . . .

Just out of curiosity, are you using Windows to test xuni? I did in fact test the Windows executable myself later on, so it's not important, but I'm just curious . . . .

[edit] 6,000th post! [/edit]

Yeah, tested on Windows XP 32bit. If this project were C++ based, I would be all over it but my C skills are so weak that I would be a complete noob playing with all of that.

I'm interested, always have been since you showed it to me a few months ago.

However, my only 'annoyance' is that it's tied with SDL, ever considered removing the dependency for SDL, and support a few others? I think you were talking about doing that before... BTW have you losly based the API on Gtk? If not you could probably borrow a few ideas, I love Gtk and it's very easy to use. Also, being constructive have you thought about 'cleaning' it up a bit? -- You know a few comments here and there, such as

Code:

---

void rescale_checkbox(struct widget_t *widget) {
   
}

---

... why that's blank!? :\

Code:

---

void save_screenshot(SDL_Surface *screen) {
    char filename[14];
    FILE *t;
    int x;
   
    for(x = 0; x < 10000; x ++) {
        sprintf(filename, "shot_&#37;04i.bmp", x);
        t = fopen(filename, "r");
        if(!t) break;
        fclose(t);
    }
   
    if(x == 10000) {
        log_message(ERROR_TYPE_WARNING, 0, __FILE__, __LINE__,
            "Screenshot not saved: shot_0000.bmp through 9999 seem to exist");
    }
    else {
        if(SDL_SaveBMP(screen, filename)) {
            log_message(ERROR_TYPE_WARNING, ERROR_FLAG_SDL, __FILE__,
                __LINE__, "Can't save screenshot: \"%s\"", filename);
        }
        else {
            log_message(ERROR_TYPE_LOG, 0, __FILE__, __LINE__,
                "Screenshot saved: \"%s\"", filename);
        }
    }
}

---

Normally I'd say 'brute force for the win', however you could simply chuck a timestamp on the end of the filename. Someone could seriously have 4000 screenshots, considered defining MAX_SCREENSHOTS instead at least ;).

[off-topic]
How are you finding 64bit Debian? I've thought about changing from OpenSuSE to Debian but need a bit of persuasion :)
[/off-topic]

News: I've uploaded xuni SVN version 80, with a win32 executable. (Sorry, no lin32 one yet. Let me know if you need it and don't feel like building it yourself.) I also separated the Doxygen documentation into a separate archive, because it was so large. Unless you want to understand the code, you probably don't need this. It's not very complete, anyway -- though font.c and memory.c are getting there.

Because I know you don't feel like scrolling to the top of the page to find the download link, here it is again: http://dwks.theprogrammingsite.com/myprogs/xuni.htm

As before, windows users, download the normal archive and the win32 archive, and extract them in the same place. The win32 executable was compiled with -g, so you can use a debugger on it now. I would appreciate it if someone could test this -- it doesn't work very well under my wine, even though the Linux-64 version does.

Quote:

---

Yeah, tested on Windows XP 32bit. If this project were C++ based, I would be all over it but my C skills are so weak that I would be a complete noob playing with all of that.

---

Eh, it's not that different from C. Most of the code is just calling other functions of mine, anyway. About the only differences from non-object-oriented-C++ are declaring variables at the beginning of blocks and multiline comments. Syntax things like that.

Quote:

---

Originally Posted by zacs7

I'm interested, always have been since you showed it to me a few months ago.

---

Ah yes, you got to see the prerelease version. ;)

Quote:

---

However, my only 'annoyance' is that it's tied with SDL, ever considered removing the dependency for SDL, and support a few others? I think you were talking about doing that before... BTW have you losly based the API on Gtk? If not you could probably borrow a few ideas, I love Gtk and it's very easy to use.

---

Actually, no. I haven't really based it on anything. I've never actually really used the GTK, nor the Win32 API, nor any GUI library, really, at least a non object-oriented one. If you have any specific comments on GTK+-ness, let me know . . . .

I have tried to keep xuni separated from the SDL more than my other projects. It's reasonably well separated. The main things I can think of at the moment are: TTF_Font is used in places -- it needs to be wrapped in a structure; SDL_Surface is used in a few places, though not very many; and some code, such as minimization, might not be supported in other libraries. If not, it could just be commented out. If I knew how to use another library I might port it. If someone else knows another library and feels like porting it, let me know what needs to be done to port it and I'll try to do it . . . .

Actually, I have a few questions about GTK and other libraries. How are widgets referenced? (You know, if you want to add a line to a specific listbox, how do you say "that listbox"?) And how are callback handlers implemented? (One for every widget, probably.) Finally, what's in the widget structure; how are different widgets represented; and how are widgets stored internally? (I'm not expecting anyone to know this, just thinking out loud . . . .)

Quote:

---

Also, being constructive have you thought about 'cleaning' it up a bit? -- You know a few comments here and there, such as

Code:

---

void rescale_checkbox(struct widget_t *widget) {
   
}

---

... why that's blank!? :\

---

Aye, it's sadly lacking in documentation. Some of my more recent code -- like memory.c -- has reasonably complete documentation, but the old code . . . nope.

As for why it is blank: it's a callback function. It doesn't have to do anything, but it's more convenient for rescale_widget() to have an empty function to call.

Did you notice the -Wno-unused-parameters? That's because of all my callback functions . . . :)

Side note: -Wno-endif-labels is required, after -pedantic, for the SDL 1.2.12 that currently comes with Debian Lenny. Someone put something like "#endif // whatever"; in ANSI C mode, it doesn't recognize that comment, and then sees extra characters after the endif. I haven't reported this yet, feel free to do so if you're so inclined. A simple /**/ comment instead would fix everything. It's very annoying -- with the number of times that file is included, you can easily get several thousand lines of warnings about it. Hence this particular warning flag.

Quote:

---

Code:

---

void save_screenshot(SDL_Surface *screen) {
    char filename[14];
    FILE *t;
    int x;
   
    for(x = 0; x < 10000; x ++) {
        sprintf(filename, "shot_&#37;04i.bmp", x);
        t = fopen(filename, "r");
        if(!t) break;
        fclose(t);
    }
   
    if(x == 10000) {
        log_message(ERROR_TYPE_WARNING, 0, __FILE__, __LINE__,
            "Screenshot not saved: shot_0000.bmp through 9999 seem to exist");
    }
    else {
        if(SDL_SaveBMP(screen, filename)) {
            log_message(ERROR_TYPE_WARNING, ERROR_FLAG_SDL, __FILE__,
                __LINE__, "Can't save screenshot: \"%s\"", filename);
        }
        else {
            log_message(ERROR_TYPE_LOG, 0, __FILE__, __LINE__,
                "Screenshot saved: \"%s\"", filename);
        }
    }
}

---

Normally I'd say 'brute force for the win', however you could simply chuck a timestamp on the end of the filename. Someone could seriously have 4000 screenshots, considered defining MAX_SCREENSHOTS instead at least ;).

---

Yes, I copied that function from a much older program of mine because I was too lazy to re-write it. ;)

Quote:

---

[off-topic]
How are you finding 64bit Debian? I've thought about changing from OpenSuSE to Debian but need a bit of persuasion :)
[/off-topic]

---

It's very nice. I have no specific good or bad things to say about the 64-bit version of Debian; I never use 64-bit specific programs, and don't program on a low enough level for it to matter that much. I do have 32- and 64-bit versions of Debian installed, but on vastly different computers, so I couldn't say if the 64-bit version is more efficient or anything, though I imagine it is.

There's only one thing about it: it can be difficult to compile or run 32-bit programs on a 64-bit system. But if you have a constant, fast internet connection, as I do not, then it's no hassle to download the right 32-bit libraries. The Debian package manager will do it automatically.

But Debian in general . . . highly recommended. It's really nice. The package management means you hardly ever break anything when you upgrade, and uninstalling things is very easy. The number of packages is astounding, and the default installation is very complete. The number of times I've gone to install something off the internet, only to find that there is a package for it, or even that I already had it installed without realizing it . . . .

I would try it, see how you like it. I know I do. Note: I've never used any other distribution of Linux to any great extent, so take this "with a truck-sized grain of salt." :)

I just tested xuni-80 on Windows XP, and it works perfectly. My wine must be messed up.

[edit] Here's another XP computer, and widget accelerator keys (like pressing 'o' for the options menu) don't seem to be working. Perhaps I broke them. :)

On another note, this 80 version also fixed that click-on-panel,-get-fullscreen-toggle bug. It's just a temporary one, probably, but it works. [/edit]

Actually, I have a few questions about GTK and other libraries.
How are widgets referenced? (You know, if you want to add a line to a specific listbox, how do you say "that listbox"?)
And how are callback handlers implemented? (One for every widget, probably.)
Finally, what's in the widget structure; how are different widgets represented; and how are widgets stored internally?
(I'm not expecting anyone to know this, just thinking out loud . . . .)

In GTK, you basically keep pointers to GtkWidgets (ie, 'that listbox') and do what you will.
Take an editbox for example,

Code:

---

GObject
    +----GInitiallyUnowned
            +----GtkObject
                    +----GtkWidget
                            +----GtkEntry
                                    +----GtkSpinButton

---

Since everything is a GtkWidget, it's possible to use them everywhere. For example, you can put editbox widgets in menus... Easily too, no different than placing a label.

For example, if you did want to change the text of an editbox (aka entry), you'd simply:

Code:

---

...
    GtkWidget * editbox;

    editbox = gtk_entry_new();
    gtk_entry_set_text(GTK_ENTRY(editbox), "xuni is awesome");      /* Note the cast from GtkWidget to GtkEntry */

    change_text(editbox);
...

void change_text(GtkWidget * widget)
{
    gtk_entry_set_text(GTK_ENTRY(editbox), "new text");
    return;
}

---

More importantly Gtk cleans up for you (you don't explicitly have to delete a widget) -- you can do:

Code:

---

GtkWidget * reusableWidget;

/* create 3 edit boxes */
reusableWidget = gtk_entry_new();
reusableWidget = gtk_entry_new();
reusableWidget = gtk_entry_new();

---

... what would appear to be a memory leak is in-fact not. In-between each line you could add some callbacks to each editbox, some text, add them to a dialog (or a container).

Seriously have a look at http://library.gnome.org/devel/gtk/stable/ (Being a Debian man, I hope you're also a Gnome man ;)). I'd suggest doing a few Gtk programs, get the hang of it then you'll probably get a lot of good ideas for xuni.

I've uploaded xuni SVN version 81. There were quite a few changes in this release, notably modularization of widget freeing code, conversion of font into a widget*, re-write of the Windows Makewins, and a re-write of save_screenshot(). :) All memory leaks that I know of are fixed. Note that the theme roundness checkbox is in a monospace font.

This version also contains Windows executables for the editor as well as ./test; and linux 32-bit exeutables as well. In separate archives, of course. You'll need to get the shared libraries yourself in order to run the linux executables.

That link again: http://dwks.theprogrammingsite.com/myprogs/xuni.htm

* In UNIX, everything is a file. In xuni, everything is a widget. ;)

Quote:

---

Originally Posted by zacs7

Quote:

---

Actually, I have a few questions about GTK and other libraries.
How are widgets referenced? (You know, if you want to add a line to a specific listbox, how do you say "that listbox"?)
And how are callback handlers implemented? (One for every widget, probably.)
Finally, what's in the widget structure; how are different widgets represented; and how are widgets stored internally?
(I'm not expecting anyone to know this, just thinking out loud . . . .)

---

In GTK, you basically keep pointers to GtkWidgets (ie, 'that listbox') and do what you will.
Take an editbox for example,

Code:

---

GObject
    +----GInitiallyUnowned
            +----GtkObject
                    +----GtkWidget
                            +----GtkEntry
                                    +----GtkSpinButton

---

Since everything is a GtkWidget, it's possible to use them everywhere. For example, you can put editbox widgets in menus... Easily too, no different than placing a label.

---

I have it set up in a similar way with xuni, except that the structure (struct widget_t) doesn't need to be casted or anything. Instead, it has a union of pointers to the different widget-specific data structures. I've been hoping that this will let me add images etc to listboxes, but it doesn't work quite yet . . . .

Quote:

---

For example, if you did want to change the text of an editbox (aka entry), you'd simply:

Code:

---

...
    GtkWidget * editbox;

    editbox = gtk_entry_new();
    gtk_entry_set_text(GTK_ENTRY(editbox), "xuni is awesome");      /* Note the cast from GtkWidget to GtkEntry */

    change_text(editbox);
...

void change_text(GtkWidget * widget)
{
    gtk_entry_set_text(GTK_ENTRY(editbox), "new text");
    return;
}

---

---

Vote of confidence appreciated. :) It looks very simple compared to xuni . . . probably because the positions for each of xuni's widgets has to be specified. I've started implementing WIDGET_PACK_TOP, but that's only for listboxes so far.

That's another thing I want to do with xuni: name all of the public functions xuni_*, to avoid naming collision if possible.

Quote:

---

More importantly Gtk cleans up for you (you don't explicitly have to delete a widget) -- you can do:

Code:

---

GtkWidget * reusableWidget;

/* create 3 edit boxes */
reusableWidget = gtk_entry_new();
reusableWidget = gtk_entry_new();
reusableWidget = gtk_entry_new();

---

... what would appear to be a memory leak is in-fact not. In-between each line you could add some callbacks to each editbox, some text, add them to a dialog (or a container).

---

Yes, xuni does clean up for you too, though you can't just add callbacks for every widget. That was something I wanted to avoid, for some reason (probably didn't want millions of really short functions), so you can just add a panel callback which handles every widget for that panel. I think I will change this, however. It's making things unnecessarily complicated.

Quote:

---

Seriously have a look at http://library.gnome.org/devel/gtk/stable/ (Being a Debian man, I hope you're also a Gnome man ;)). I'd suggest doing a few Gtk programs, get the hang of it then you'll probably get a lot of good ideas for xuni.

---

Perhaps I shall, we'll have to see . . . BTW, I already have the GTK+ development libraries installed and a tutorial downloaded, because I had much the same thought a while ago. ;)

And yes, I do use Gnome almost all of the time. I prefer some KDE programs, however. So I have a weird mix of programs running: gnome-terminal, kdevelop, meld, kdesvn, nautilus, kompare, epiphany, . . . .

I take it you use Gnome? What IDE do you use? KDevelop is very nice . . . I tried downloading Anjuta (and Geany) a few days ago because I saw them in someone's signature, but neither is as nice as KDevelop. Geany is a nice lightweight editor, though; nicer than Kwrite or Kate.

> I take it you use Gnome? What IDE do you use?
Yeah Gnome, I've never really found a nice IDE -- So i've stuck with make and SciTE :)

That's sort of what I used to use . . .

In case anyone's still interested, I've uploaded a modified version of xuni, SVN version 86.
http://dwks.theprogrammingsite.com/myprogs/xuni.htm

Again, just 64-bit Linux and Windows executables -- no 32-bit Linux ones. Documentation is still separated.

There are lots of known bugs, most significantly that listboxes do not scroll properly the first frame (or rather reposition) after a rescale event. Don't try to select a listbox item when they're not scrolled properly -- xuni will crash with a segmentation fault after listbox_sel_item() returns 0. (Easy to fix, but that's not the root problem.) I haven't tried to fix this one yet, because I'm planning on completely re-writing the coordinate system, so it would probably be a waste of time.

Anyway -- I have a question about reflection. How can I have, for example, the string "something" in my XML file, and then execute the function something() that is likely in another object file or library? I could do it with dlopen() and friends under Linux, but I don't really know how to do it under Windows (I heard rumours about LoadLibrary()); and besides, I was hoping for a reasonably cross-platform solution, perhaps a library of some sort.

D-Bus looks interesting . . . has anyone tried it from C? http://dbus.freedesktop.org/doc/dbus...-tutorial.html

Any other suggestions?

I've noticed you're using libexpat, a bit of an over kill don't you think?

I'd suggest libmxml -- or if you want something bigger libxml2

> D-Bus looks interesting . . . has anyone tried it from C?
Sort-of, I've been involved with projects where it is being used, ie GnomeBaker. Works well.

I do have a suggestion, to showcase xuni and codeform -- a graphical editor written in xuni with source highlighting (codeform) :)... food for thought
Also, perhaps look into GLib, once you use it you don't want to "not use it" :(

Quote:

---

Originally Posted by zacs7

I've noticed you're using libexpat, a bit of an over kill don't you think?

---

Eh, it's one of the simpler libraries I could find. It doesn't even support writing XML.

Quote:

---

I'd suggest libmxml -- or if you want something bigger libxml2

---

I tried to use libxml2, but all of those functions hopelessly confused me. :) However, I wrote an expat layer for xuni, because I'd always planned to add libxml2 support when I felt up to the task.

I've never heard of libmxml -- I'll have to look at it.

Quote:

---

> D-Bus looks interesting . . . has anyone tried it from C?
Sort-of, I've been involved with projects where it is being used, ie GnomeBaker. Works well.

---

Turns out that the SDL actually has dynamic library loading support. Of course it does -- the library is usually a dynamic one. SDL_LoadLibrary()+SDL_LoadFunction()+SDL_UnloadLib rary() are the relevant functions. I'm not sure if they're part of the standard interface or not, since they don't show up in documentation, but my copy of the SDL 1.3 source code also has them. I think they'll be there for quite some time yet.

Just in case, I also implemented a dlopen() version.

Oh, and BTW -- libtool's dlopen() wrapper, which supports several platforms, is called libltdl, not libtltdl as the C++ mini dlopen() how-to claims. :)

Quote:

---

I do have a suggestion, to showcase xuni and codeform -- a graphical editor written in xuni with source highlighting (codeform) :)... food for thought

---

Aye, well, when I recently printed some (okay, all -- long story) of xuni's source code, I couldn't resist highlighting it with codeform beforehand. :) In the Dev-C++ style, which looks reasonably good in black-and-white.

I will probably implement something like that once I get around to implementing textareas. A text editor isn't much use if you can only have one line. Pretty much everything else I'd need is implemented, including coloured text support.

Quote:

---

Also, perhaps look into GLib, once you use it you don't want to "not use it" :(

---

It looks interesting, for sure. I'm just worried about portability. Probably unfoundedly, but there you have it.

And where's the fun in cobbling together libraries when everything's already written for you? ;)

Uploaded xuni again -- SVN version 89 this time. I only have a 64-bit Linux executable, and it's included with the documentation in one big archive.

I've implemented libmxml support. It was a bit difficult, but it works properly now.

(There's more than one library called mxml, which was confusing me. mxml.sourceforge.net is another library by the same name, but not nearly as good.)

I trashed my custom Makefiles and started using autotools. We'll see how it works.

I also started using dynamic library loading, as I mentioned in my last post. It's really quite neat. In an XML file, you can use something like this (from menu.xml):

Code:

---

        <handler file="src/test/test.so">
            <init>init_menu</init>
            <start>start_menu</start>
            <event>menu_event</event>
            <perform-click>menu_perform_click</perform-click>
            <paint>paint_menu</paint>
            <free>free_main_menu</free>
        </handler>

---

Then those functions are called from the library specified, which is loaded dynamically with SDL_LoadObject() (which usually uses dlopen() etc on Linux). (Is .so the standard extension for dynamic libraries on linux systems?)

I'm not sure how to do this in Windows, however, so there's no Windows executable yet. I plan to allow static library loading with the same interface, so there will be a Windows executable eventually. You just might have to re-compile xuni more often in Windows, should you be developing it there. Which I don't. :)

Listboxes haven't been fixed yet. I don't feel like re-writing the coordinate system, but I suppose it has to be done. Any suggestions? Here's what I'm thinking of at the moment:

Code:

---

enum pos_pack_t {
    POS_PACK_NONE,
    POS_PACK_TOP,
    POS_PACK_BOTTOM
};

struct scale_pos_t {
    double x, y, w, h;
};

struct clip_pos_t {
    int xoff, yoff;
    int xclip, yclip, wclip, hclip;
};

struct pos_t {
    enum pos_pack_t pack;
    struct scale_pos_t scale;
    struct clip_pos_t *clip;
    SDL_Rect real;
};

---

I'm trying to cater to several needs here, mostly because of listboxes.

• pos_t::scale. Firstly, positions are specified as percentages (doubles), to allow rescaling and so on.
• pos_t::real. The percentage positions are converted to integers, for painting and click detection. Because these values are used so widely, storing the converted values is probably a good idea.
• pos_t::clip::*off. The positions must be allowed to shift, for example for listbox items and scrollbar boxes. However, the original positions must be maintained for rescaling and so that the scrollbar box, for example, can be restored to its original place.
• pos_t::clip::*clip. The visible parts of the widget must be changable, for example for listbox items that are scrolling out of view. I could use SDL_SetClipRect(), but it feels like cheating, is less efficient, and makes special effects like fading out listbox items harder. It also makes click detection very difficult. (Another library, called SDL_gui, uses this approach and has tons of issues with being able to select widgets that have been scrolled out of view.)
• pos_t::pack. Some items are "packed", for example listbox items. For POS_PACK_TOP, for example, a widget is put as close to the top of the area of its parent widget without overlapping any other widgets. If some widgets shrink or grow larger, the other widgets automatically move to accommodate this.

It seems pretty redundant and overly complex. I also don't want the position structure to be that big -- xuni uses enough memory as it is.

Any thoughts? Comments? Suggestions? Comparisons with more sane systems from other widget toolkits? . . . .

[edit] I looked at the GTK's packing system. It's very interesting.
http://library.gnome.org/devel/gtk/u...ontainers.html
http://library.gnome.org/devel/gtk/unstable/GtkBox.html

There are start and end positions, so you can pack items from those two points . . . I have implemented, basically, a limited version that only lets you pack from the start. Maybe I should reconsider . . . . [/edit]

That's pretty awesome. You don't want to make it too complex however, if someone is going to use xuni as a UI for their game they could be turned away if it's over done ;)

BTW, Who did the logo? It's awesome!

Quote:

---

Originally Posted by zacs7

That's pretty awesome. You don't want to make it too complex however, if someone is going to use xuni as a UI for their game they could be turned away if it's over done ;)

---

I think it's probably reached that stage already . . . .

Quote:

---

BTW, Who did the logo? It's awesome!

---

Yours truly. I used the GIMP, the Frosty plugin. Launch the GIMP, click Xtns->Script-Fu->Logos->Frosty. I can't remember the exact font and size that I used (FreeSans comes to mind), but I have it written down somewhere. :)

I accidentally posted the coordinate system that I'm currently using, which is why it's badly implemented. Here's more what I'm planning to convert it to.

Code:

---

enum pos_type_t {
    POS_NUMBER,
    POS_SCALE,
    POS_PACK
};

enum pos_pack_t {
    POS_PACK_TOP,
    POS_PACK_BOTTOM
};

struct axis_pos_t {
    enum pos_type_t type;
    union {
        double scale;
        int absolute;
        enum pos_pack_t pack;
    } num;
};

struct xy_pos_t {
    struct axis_pos_t x, y, w, h;
};

struct pos_t {
    struct xy_pos_t pos;
    struct xy_pos_t *offset;
    struct xy_pos_t *clip;
    SDL_Rect real;
};

---

I've registered xuni as a project on Sourceforge. sourceforge.net/projects/xuni

Right now there's not a lot there, but it's newsworthy nevertheless.

You can now grab the latest source code with:

Code:

---

svn co https://xuni.svn.sourceforge.net/svnroot/xuni/xuni/trunk xuni-trunk

---

Note the double "xuni". Until I figure out how to move everything in "xuni/trunk" to just "trunk", that's what you have to use.

BTW, Google Code > sf.net IMO. Since it's not slow, and it's set up more securely.

Google Code looks interesting. Why didn't you tell me about it before? Because I didn't ask, of course. :)

How is it set up more securely?

> How is it set up more securely?
Anyone can read your database, everything you have really on sf.net as long as they have an account (They don't even need to be a member of your project). However, that's not the case for Google Code.

I didn't tell you about it before, because it's *sort of* new -- and I've only just started using it myself ;)

I see someone checked out my repository besides myself -- was that you, zacs7? ;)

I've done a lot of work for SVN version 90. Here's the SVN commit log message. (It's here for impressiveness. I don't expect anyone to read it! :p )

Code:

---

------------------------------------------------------------------------
r90 | dwk | 2008-04-05 02:00:42 -0600 (Sat, 05 Apr 2008) | 151 lines

=== Overview ===
+ Build system
    - Changes
    - File management
+ Valgrind
    - Text cursors freed
    - Memory errors
    - Textbox memory errors
+ Windows support
    - Better Windows support
    - Problems with Windows support
+ Checkboxes
    - Checkboxes are proper composite widgets
    - Checkboxes selectable by text
+ Textboxes and labels
    - Textbox click position bugfix
    - Previous attempted fix
    - Text cursor position rounding
+ Scrollbars
    - Positions: ints to doubles
    - Proper sized seek boxes
+ Refactorings
    - paint_widget() etc static
    - struct xuni_t first
    - Function renaming
+ Reference counter
    - Memory block types
    - Fixed memory type errors
+ Miscellaneous
    - percentdoc.pl
    - Bugfixes
    - Publishing
    - Notes

=== Build system ===

*** Changes ***
- Added the DYNAMIC_HANDLERS conditional to configure.ac to allow easier
compilation with different loadso versions.
- Fixed filecount.sh so that it does not strip out real files. The make wc taret
has less output than it used to, which was not reflected here.
- Made runwin more space efficient -- it now creates symlinks instead of copies
of files.

*** File management ***
- Removed configure from SVN control.
- Removed all depend files from SVN control.
- Removed the entire dist/ directory, along with its files Makefile and Makewin.
The "make dist" target of autotools rendered it unnecessary.
- Moved calc.h, calc.y and the generated calc.c from src/ to src/resource/.
- Renamed src/resource/calc.h to calcfunc.h. calc.h is now automatically
generated by bison/yacc.

=== Valgrind ===

*** Text cursors freed ***
The SDL_Cursor for the textbox text cursor is now freed. It is implemented in a
kludgy way (though much better than it was -- there are at least no static
variables not). Still, xuni once more shows up no memory leaks in Valgrind. The
changes are mostly in graphics.h and loop.c.

*** Memory errors ***
Though there are no memory leaks under normal conditions, Valgrind reports
several memory errors. They all come from loop.c line 390 (at the call to
SDL_WaitEvent()), start_element() at libexpat.c:204, and the textbox code which
is explained in greater detail below. The cause of the former two cases is still
unknown.

*** Textbox memory errors ***
Elements of textboxes, including the text widget, are rescaled before the
textbox itself. However, the "text" label sub-widget of textboxes depends on the
size of its base widget (widget->base->pos->real.w) to tell how much to scroll
itself. This means that widget->base->pos->real.w is sometimes uninitialized.

The best way to fix this would be to have more specific events than just
"rescale" and "reposition". This should be done, anyway, for efficiency reasons.

=== Windows support ===

*** Better Windows support ***
Implemented a proper LOADSO_STATIC_VERSION, so that Windows executables are
possible. For this STATIC loadso type to work, each xuni application has to
implement its own xuni_loadso_load_function() that uses string_to_function() to
convert function names as string to function pointer addresses. All of the code
is then statically linked together so that the functions can be resolved.

Compiled and tested xuni under wine, and ran it on real XP system as well -- it
worked perfectly. Note that the static loadso version works just fine under
Linux as well.

*** Problems with Windows support ***
- Compiling a windows executable is still difficult. It requires editing
loadso.h and using custom Makewins.
- The xuni icon under Windows does not display on the window, but does on the
taskbar.

=== Checkboxes ===

*** Checkboxes are proper composite widgets ***
Checkboxes used to have click detection in "checkbox/box". In other words, the
button of checkboxes would receive the click rather than the checkbox widget
itself. (This is how it used to be set up for textboxes and so on, before the
advent of WIDGET_VISIBILITY_INDEPENDENT and WIDGET_VISIBILITY_NOT_COMPOSE.

*** Checkboxes selectable by text ***
Checkboxes can now be toggled by clicking on the text of the textbox. With the
help of some code in paint_box(), the box even displays the right hover and
active artwork. However, there are still some bugs relating to when the check
image is displayed.

=== Textboxes and labels ===

*** Textbox click position bugfix ***
In gui.c (new line 1014), "widget" was being used instead of "w". This made the
code that decides which where to put the text cursor when a textbox is clicked
on use the base textbox instead of the label widget, which was messing up the
alignment.

*** Previous attempted fix ***
This was attempted to be fixed by code in width_to_label_pos() to "round" the
position of the textbox cursor -- except it had to move it the wrong way to make
it look right. And with different theme roundnesses it all broke down.

*** Text cursor position rounding ***
The "rounding" of width_to_label_pos() works correctly now. The position that
the textbox editing cursor appears in is the closest position. For example, if
one clicks on the left half of a character, the cursor will go to the left of
that character, and likewise for the right.

=== Scrollbars ===

*** Positions: ints to doubles ***
Scrollbar positions, which used to be ints, are now doubles. This means that
they work much better when they are rescaled. Several functions, such as
get_scollbar_pos() and set_scrollbar_box(), were introduced or modified to
implement this change.

*** Proper sized seek boxes ***
Thanks mainly to calculate_seek_height(), the seek boxes of scrollbars are now
as expected. When all of the listbox or whatever data fits into one screen, the
scrollbar is as large as can be; and it gets progressively smaller as more data
is added.

=== Refactorings ===

*** paint_widget() etc static ***
Replaced nearly all calls to reposition_widget(), rescale_widget(),
paint_widget(), and free_widget() with calls to widget_event(). These functions
still exist and are still called in a convoluted series of functions in
widgets.c, but they are static now.

*** struct xuni_t first ***
Made a few more functions (such as call_deactivate_func()) take a struct xuni_t
as their first parameter. The most notable functions that still do not do this
are the application callback functions like paint_game(), which take a void
*vdata parameter first. (They take a xuni_t in varying positions.)

*** Function renaming ***
Renamed lookup_widget_nameid() to widget_nameid_follow(), which is intended to
be similar to widget_nameid_access(). (The "follow" function follows more than
one nameid, the "access" one only does one nameid.)

*** calc.y ***
- Renamed NUM to NUMBER.
- Tried to implement a [f]lex parser, which is why calc.h became automatically
generated.

=== Reference counter ===

*** Memory block types ***
Implemented memory block types a little further. Blocks allocated for the SDL
(i.e., for SDL_Surfaces) are now tags as such, though they are not freed
properly just yet for unknown reasons.

Added a yet-unused MEMORY_BLOCK_TYPE_LOADSO_OBJECT.

*** Fixed memory type errors ***
At old lines 579-581 (new lines 569-573), memory.data[pos].type was being used
after being freed. In effect, each block was freed according to the type of the
block following it. With only one block type, this did not matter very much, but
it was causing seg faults with the new block types. (SDL_FreeSurface() was being
called instead of free().)

=== Miscellaneous ===

*** percentdoc.pl ***
Created doc/percentdoc.pl, which figures out what percentages of xuni's
functions and other objects are documented. It parses the Doxygen output, and is
completely independent of xuni. Currently, it says:

    *** Number and percentage of entities and functions that are documented ***
Source file name          | All entities    | Normal funcs    | Static funcs
... details for each source file ...
    *** Total ***        |  73/515  14.17% |  45/249  18.07% |  4/168  2.38%

So 18% of xuni's non-static functions are documented. (This is up a few percent
from the last revision.)

*** Bugfixes ***
- Made the options->graphics menu no longer use options_theme_deactivate();
instead, it uses the proper options_graphics_deactivate(). This was preventing
the graphics screen mode textbox from working.
- The options menu was using options_theme_deactivate() as well. Now, it uses no
deactivate function at all.
- xuni::theme::current was not being initialized. On Linux, it was initialized
to zero by default and everything was fine. On some Windows/wine systems, it was
fine too; on others, it resulted in no theme being assigned. This was discovered
with Valgrind and helped debugged by memset()'ing malloc()'d memory.
- Made the arrays of function pointers in <widget>_widget_event() static.
Possible stack overflows were being encountered in some circumstances, and it
needed to be done anyway.

*** Publishing ***
- Registered xuni as a project on sourceforge.
- Changed xuni's version number from 1.0.0 to 0.3.0.

*** Notes ***
- Added Doxygen documentation comments to widgets.c, xuni.c and other source
files.
- Put [done] in several TODO list items, and added a few more items as well.
- xuni is now 11945 lines long!

------------------------------------------------------------------------

---

Now that I've set up an easy way to compile 32-bit Linux executables, I should be able to post binaries for this version pretty soon. Until then, check it out from sourceforge if you're interested. (I've asked sf to update my repository. It might be a little while.)

Which brings up a point -- how long are most SVN commit logs? How often do most people commit? I'm pretty sure I'm committing less often than the norm, not that it matters too much when I'm the only one working on the project.

I've created and uploaded binaries for xuni SVN version 90. The usual 32-bit and 64-bit Linux as well as 32-bit Windows ones.

Discussion: http://sourceforge.net/forum/message.php?msg_id=4900438
Direct download link: http://sourceforge.net/project/showf...ease_id=588677

If you wish, download the archive appropriate for your platform, and let me know how well it works there . . . .

Now that I've gone and done all of this for version 90, SVN version 91 is available from Sourceforge via SVN. :) It's a lot better, too, with many, many bugfixes. I'll try to get binaries for it as soon as possible . . . .

[edit] As you can see, I've decided to stick with Sourceforge for now. Mainly because I've already started using it, and switching now without getting a feel for how Sourceforge is doesn't seem like a very good idea. [/edit]

Seriously, I'm in the stage of requiring a GUI for my game -- if you manage to port xuni to plain openGL I'd really love to use it :)

There really aren't any nice pure openGL toolkits, (of course it wouldn't truely be pure) -- unless you provide some input/output hooks, which the developer then hooks up.

Converting xuni to use OpenGL might be worth trying, because removing SDL dependency would make xuni a lot more portable, and I need more experience with OpenGL anyway. It would be a pretty big job, though. I'll look into it nevertheless.

Thanks for continuing to post in this thread, it makes me feel appreciated. :)

That's okay, I don't want to leave you in the corner by yourself :)

I also need more expirience with OpenGL that's why I asked ;)

Weird. I got Sourceforge to replace my SVN repository again. They replaced my repository by adding each revision, one by one. I performed some SVN commands; each time I did so, the version number went up.

The whole process took several minutes. I can see how replacing a large SVN repository might take some time.

Anyway, the reason I was trying this was because I wanted to make sure this worked. I've uploaded SVN version 92, but again there aren't any binaries just yet. You can see the changelog like this.

Code:

---

svn log -r 92 https://xuni.svn.sourceforge.net/svnroot/xuni/xuni/trunk

---

Note that version 92 isn't as stable as previous versions. Oh, it runs, but the new horizontal scrollbars look rather strange. ;)

Seriously, If you're willing to turn this into a full on project I'd love to help. I need team expirience and a project atm :)

Mainly because there isn't a plain, simple, full-featured UI toolkit for OpenGL written in C :)

Note: binaries for xuni-0.3.0-svn-92 released. http://sourceforge.net/project/showf...roup_id=223060

While I have a project, I need team experience too. :) I'd love to have your help.

Your first assignment: convert xuni to OpenGL. :)

Just kidding. Like I said, it would be a pretty big job. xuni uses a lot of SDL-specific functions.

Code:

---

=== SDL (note: includes SDL_framerate functions from SDL_gfx)
SDL_CreateCursor SDL_CreateRGBSurface SDL_DisplayFormatAlpha SDL_EnableKeyRepeat
SDL_EnableUNICODE SDL_EnableUNICODE SDL_FillRect SDL_FillRect SDL_framerateDelay
SDL_FreeCursor SDL_FreeSurface SDL_FreeSurface SDL_FreeSurface SDL_GetAppState
SDL_GetCursor SDL_GetError SDL_GetError SDL_GetMouseState SDL_GetMouseState
SDL_GetMouseState SDL_GetRelativeMouseState SDL_GetRGBA SDL_Init
SDL_initFramerate SDL_ListModes SDL_LoadFunction SDL_LoadObject SDL_LockSurface
SDL_MapRGB SDL_MapRGB SDL_PollEvent SDL_Quit SDL_RWFromFile SDL_SaveBMP_RW
SDL_SetColorKey SDL_SetCursor SDL_setFramerate SDL_SetVideoMode SDL_ShowCursor
SDL_UnloadObject SDL_UnlockSurface SDL_UpdateRect SDL_UpperBlit SDL_WaitEvent
SDL_WarpMouse SDL_WarpMouse SDL_WM_GrabInput SDL_WM_IconifyWindow
SDL_WM_SetCaption SDL_WM_SetIcon SDL_WM_ToggleFullScreen
=== SDL_gfx
gfxPrimitivesSetFont gfxPrimitivesSetFont rotozoomSurface SDL_framerateDelay
SDL_initFramerate SDL_setFramerate stringRGBA vlineRGBA zoomSurface
=== SDL_image
IMG_Load
=== SDL_ttf
TTF_CloseFont TTF_CloseFont TTF_FontHeight TTF_Init TTF_OpenFont TTF_Quit
TTF_RenderText_Blended TTF_SetFontStyle TTF_SizeText

---

(I'm sorry for the duplicate functions. Blame ld, not me.)

And then there's all of the SDL macros/constants used throughout the code, i.e. SDLK_ESCAPE and so on.

I know very little about OpenGL, but I think it would be possible to convert all of xuni's SDL dependencies into OpenGL ones. A good start would be reviewing the prototypes in graphics.h (the names are reasonably descriptive) to see if OpenGL has an equivalent.

You're right about there not being very many GUI toolkits for OpenGL, though. Agar is pretty nice, and there are others out there, but they are nearly all C++.

By the way, do you have any experience with git or Mercurial or bzr? (I have very little experience with any VCSs outside of Subversion, and a bit of CVS.) If someone else were to help me with xuni, it would probably have to use a distributed version control system instead of SVN. The main reason for this is that I'm using a local SVN repository as the "master" one that I commit to and everything, because I so rarely get online. I then replace the SVN repository on Sourceforge with mine whenever I get around to it. So this wouldn't work very well with multiple developers.

BTW, in a modified version of SVN 92, I made xuni only rescale images when they need to be painted. It just means it's a bit slow when you switch to a menu for the first time, for example. It helps xuni's memory consumption, assuming you don't visit all of the menus, and speeds up rescaling immensely.

I'm considering keeping xuni this way. Or maybe make another thread to do rescaling, so that xuni is repainted at a reasonable rate. On slower computers xuni was taking several seconds (sometimes five or six) to rescale everything, especially since the addition of the new theme glowbox, which has very big images.

You should see glowbox, by the way. I think it's quite neat, but not neat enough to make it xuni's default theme. ;)

Quote:

---

By the way, do you have any experience with git or Mercurial or bzr? (I have very little experience with any VCSs outside of Subversion, and a bit of CVS.) If someone else were to help me with xuni, it would probably have to use a distributed version control system instead of SVN. The main reason for this is that I'm using a local SVN repository as the "master" one that I commit to and everything, because I so rarely get online. I then replace the SVN repository on Sourceforge with mine whenever I get around to it. So this wouldn't work very well with multiple developers.

---

I could help you out if you need help in bzr.

I appreciate your offer. I'm sure I'd have a lot of questions about it, judging by how long it took me to figure out SVN . . . .

Did you ever try out any other systems? What made you choose Bazaar?

Quote:

---

Did you ever try out any other systems?

---

Subversion, and to a lesser extent, CVS.

Quote:

---

What made you choose Bazaar?

---

I wanted to keep a local SVN repository but also publish to a Sourceforge SVN repository. Sounds familiar? :p

I did not choose git and Mercurial because I did not hear of them at the time. Ironically, I got to know of both after I subscribed to the Bazaar mailing list, but the poor Windows support of git discouraged me from switching even though Bazaar was slow then (and still is now, where projects the size of Linux or Mozilla are concerned).

Quote:

---

Originally Posted by laserlight

Subversion, and to a lesser extent, CVS.

I wanted to keep a local SVN repository but also publish to a Sourceforge SVN repository. Sounds familiar? :p

---

Yes, indeed. ;)

Quote:

---

I did not choose git and Mercurial because I did not hear of them at the time. Ironically, I got to know of both after I subscribed to the Bazaar mailing list, but the poor Windows support of git discouraged me from switching even though Bazaar was slow then (and still is now, where projects the size of Linux or Mozilla are concerned).

---

Windows support would be pretty important to me, I think. But I've heard that git's Windows support is better now. http://en.wikipedia.org/wiki/Git_%28...29#Portability
Of course, I've never actually tried it.

I'm pretty sure that speed wouldn't be too much of a problem for quite a while in this case. :)

So you would recommend Bazaar then? How well do SVN repositories tend to convert to bzr ones? (I see there's something called svn2bzr, but I wouldn't know how well it works.)

[edit] Do you need a "master" repository with distributed version control systems? If so, do Sourceforge or Google Code support git or bzr or anything? [/edit]

Quote:

---

So you would recommend Bazaar then?

---

Yes, I have been pretty happy with Bazaar so far :)

However, note that I am biased since I cannot honestly recommend git or Mercurial because I lack experience with them, e.g., the only reason I installed Mercurial was to figure out how the Netbeans Mercurial plugin worked.

Quote:

---

How well do SVN repositories tend to convert to bzr ones?

---

Quite well, apparently. For some reason, bzr-svn, a plugin that allows bzr to interoperate with a SVN repository is all the rage at the moment.

Quote:

---

I see there's something called svn2bzr, but I wouldn't know how well it works.)

---

Unfortunately, neither do I as I now entirely work with Bazaar branches. However, as long as you keep your original SVN repository backed up, it should be safe to just give an import a try.

A good workflow that I recommend for a team is to keep a branch online and treat it as the trunk (or mainline, or whatever you want to call it), and then have a mirror of the trunk in the form of a checkout (or a branch). The development would occur with one or more working branches, each of which is for the development of a particular feature. The checkout of the trunk and the working branches would all reside in a shared repository in order to save space. If multiple developers work on the same feature, they could publish the feature branch online, and then either adopt the same workflow (keep a mirror of the feature branch and have a working branch), or use a centralised workflow with checkouts.

Oh, and concerning Bazaar terminology:
branch => akin to a SVN repository
checkout => akin to a SVN checkout
repository => storage area for branch/checkout history
shared repository => shared storage area for history of related branches/checkouts

Quote:

---

Do you need a "master" repository with distributed version control systems? If so, do Sourceforge or Google Code support git or bzr or anything?

---

Yes, but there is nothing special about it other than that everyone agrees that a particular repository/branch is The One. As far as I know, neither Sourceforge nor Google Code explicitly support any of the three distributed VCS mentioned in this thread, but you can publish a branch online without installing software on the server, though with the version control software installed operations would be faster. Launchpad explicitly supports Bazaar (they are both funded by Canonical, which also sponsors Ubuntu Linux), but I prefer to use my own VPS.

I meant to reply to this earlier. Sorry for the delay, I got started reading some tutorials. :)

I just mentioned git, Mercurial, and bazaar because those are the three I gather are the most common. I would prefer to use a reasonably common VCS.

I think I will experiment with all three of them. Create some new repositories, try exporting xuni from SVN to them, and so on.

Thanks for the information about bzr. I'll save this page and read it in more detail. :)

BTW, you can apparently get the latest source code for the Linux kernel like this:

Code:

---

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

---

Just thought someone might be interested. ;)

I've decided to try git, because I hear that its Windows support is not bad, and because tracking content rather than files strikes me as an interesting idea . . . I'll let you know how it works. git's index is really nice, for an SVN user like myself.

I'm trying to upload xuni SVN 93 right now, which should be the last SVN version.

[edit] It should have worked. Note that I didn't test the binary archives, which was probably a bad idea. [/edit]

GNU autotools are annoying me. They're much better than my custom Makefiles, it's true, but they don't work on Windows and they're pretty slow. What other build systems are there out there?

I've heard of SCons, and cons looks similar except for Perl instead of Python (which would be good for me, because I know more Perl than Python). I've never tried either, however. zacs7 mentioned cmake. I did look at it, and it looks pretty complete, with rather similar syntax to autotools.

What else is out there?

I should probably just leave this thread alone, but I thought I'd just mention one last thing: I've uploaded yet another version of xuni. http://sourceforge.net/project/showf...kage_id=269611

I called it version git-1, because it's the first time I've made a binary release of xuni since I started using git.

Which went okay, by the way. I like git better than SVN, for sure. On the other hand, I haven't set up an online repository yet, which was sort of the whole point of using git. :)

Quote:

---

Originally Posted by dwks

GNU autotools are annoying me. They're much better than my custom Makefiles, it's true, but they don't work on Windows and they're pretty slow. What other build systems are there out there?

I've heard of SCons, and cons looks similar except for Perl instead of Python (which would be good for me, because I know more Perl than Python). I've never tried either, however. zacs7 mentioned cmake. I did look at it, and it looks pretty complete, with rather similar syntax to autotools.

What else is out there?

---

Bakefile!!!

http://www.bakefile.org/

I love it. :D

Bakefile, hmm? It looks interesting. But how is it different from/better than other systems?

Quote:

---

Originally Posted by dwks

Bakefile, hmm? It looks interesting. But how is it different from/better than other systems?

---

Well it uses XML for one, and it is more akin to Makefiles than other systems IMO....
I can't tell you if it is "better" than other systems, but I do know that it is simple, and easy to use (for me at least).

I'm not really versed in other systems, although I've heard of them (Scons, CMake, etc.)
Anyways, you could always try it out. :)

I do like XML. I'll have to try it. :)