xuni: a Graphical User Interface Widget Toolkit

This is a discussion on xuni: a Graphical User Interface Widget Toolkit within the Projects and Job Recruitment forums, part of the Community Boards category; That's sort of what I used to use . . . In case anyone's still interested, I've uploaded a modified ...

  1. #16
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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?
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  2. #17
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    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"
    Last edited by zacs7; 03-18-2008 at 03:39 PM.

  3. #18
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    Quote Originally Posted by zacs7 View Post
    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.

    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.

    > 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.

    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.

    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?
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #19
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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]
    Last edited by dwks; 03-26-2008 at 10:37 PM.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  5. #20
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    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!

  6. #21
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    Quote Originally Posted by zacs7 View Post
    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 . . . .

    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;
    };
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  7. #22
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  8. #23
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    BTW, Google Code > sf.net IMO. Since it's not slow, and it's set up more securely.
    Last edited by zacs7; 04-02-2008 at 03:43 PM.

  9. #24
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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?
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  10. #25
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    > 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

  11. #26
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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! )
    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&#37; |  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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  12. #27
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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]
    Last edited by dwks; 04-11-2008 at 11:10 PM.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  13. #28
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    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.
    Last edited by zacs7; 04-13-2008 at 06:54 AM.

  14. #29
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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.
    Last edited by dwks; 04-14-2008 at 12:27 AM.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  15. #30
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    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

Page 2 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 1
    Last Post: 05-31-2003, 10:07 AM
  2. Contest Results - May 27, 2002
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 18
    Last Post: 06-18-2002, 02:27 PM
  3. Creating a User Friendly Interface.
    By jeeva in forum Linux Programming
    Replies: 5
    Last Post: 12-07-2001, 03:14 AM
  4. GUI (Graphical User Interface) Help Needed
    By Unregistered in forum C++ Programming
    Replies: 1
    Last Post: 10-11-2001, 11:35 AM
  5. Non-Standard User Interface
    By Eugene in forum Windows Programming
    Replies: 1
    Last Post: 08-29-2001, 10:43 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21