Your IDE enviroment settings/style?

[mrmclovin]

Hello!

I was wondering if someone out there could share their code-editor settings, like font and color. I'm getting tired of the boring white background with blue keyword highlightning and I can't really find a setting that saticfy me. Any tips?

[Klaim]

Visual Studio in C++ dev style + Visual Assist + ClearType activated + Consolas font (specially done for code visualisation).

[betajaen]

I've been using this style for almost two years now. Font is called "Inconsolta" and I use a colour scheme from TextMate called Monokai.

Also; I'm not a big fan on tool bars or menus. All I need is Ctrl+B to build my project and I'm happy.

[johnhpus]

I made this post over a year ago, but I still use the blue one on the left

http://www.ogre3d.org/phpBB2/viewtopic. ... 6f4e2718c6

The VS settings file is still at that pastebin link if you want to try it out.

[johnhpus]

Also; I'm not a big fan on tool bars or menus. All I need is Ctrl+B to build my project and I'm happy. Smile

You always build, never just compile one file? Blasphemy

[mrmclovin]

I've been using this style for almost two years now. Font is called "Inconsolta" and I use a colour scheme from TextMate called Monokai.

Also; I'm not a big fan on tool bars or menus. All I need is Ctrl+B to build my project and I'm happy.

I love your color theme. I've seen some screenshots of yours showing your IDE in the NxOgre forums and I have been trying to find the post for a couple of weeks now, but to no avail. Anyhow, glad you posted here. I'm going to change theme right away ..

[nikki]

I use Vim with the 'wombat' colour scheme. Ocassionally, also Code::Blocks with the default theme.

[nullsquared]

<img>

Just something that really annoys me in your screenshot, why is everything prefixed with Jii even though it resides in the namespace Jii?

As for me, everything's at defaults except for the font size, because apparently whoever builds Code::Blocks has a 640x480 screen size

[betajaen]

It's old code (Jii was the image code and Jive was the GUI system). I plan to replace with a more modern GUI system called Chocolate.

To be fair that image is about two years old now, this is a more recent screen shot of my IDE.



Click for a bigger image.

[nullsquared]

Anyways, my environment:

yes, that's a new GUI that I might just release

[KungFooMasta]

Any details on this system? Is it a standard GUI library? What features does it have?

[nullsquared]

Any details on this system? Is it a standard GUI library? What features does it have?

Not much details yet. It's not the standard "textbox and windows and titlebars and input boxes and <...>" GUI, though it does indeed contain some of those features.

Basically, it's a GUI that gets added to on-demand as I need more features from it.

Sounds pretty stupid, doesn't it? Here's the catch. It's meant to be completely straight-forward and the coder is in complete control with a very boost-like style:

Code: Select all

// all it takes to create a full GUI

<make sure Ogre::Root is initialised with at least 1 scene manager>

using namespace engine; // obviously namespaces will need to be fixed up if I release this

// create the master widget
gui::sheet sheet("main");

// create a quick image for display
gui::panelPtr img(new gui::panel("img"));

// for example, to debug your gbuffer
img->textureName("gbuffer_0");
img->size(Ogre::Vector2(196, 196));

// don't allow dragging it for whatever reason
img->movable = false;

// cycle through the gbuffer images if it's clicked on
void application::debugGbufferClick(gui::event e)
{
    // on a click, the user data is the mouse button clicked
    mouseButton id = boost::any_cast<mouseButton>(e.misc);
    if (id == MB_LEFT)
    {
        // very hacky way of doing this, I don't suggest, but just for an example
        std::string n = e.caller->textureName();
        unsigned count = boost::lexical_cast<unsigned>(n[n.size() - 1]);

        if (++count >= 4) count = 0; // only 0-3 gbuffers

        e.caller->textureName("gbuffer_" + boost::lexical_cast<std::string>(count));
    }
}

// bind the event listener for a mouse click
img->setEventCallback(gui::EVT_CLICK, boost::bind(&application::debugGbufferClick, boost::ref(theApplication), _1);

sheet->addChild(img);
// doesn't matter if img falls out of scope here anymore

render loop // the render loop would probably be best a render target listener
// attached to the window, _unless_ you run your own render loop (no renderOneFrame())
{
    // render main scene
    <...>

    // render sheet
    sheet.render(viewport);
}

// input injection is pretty standard
onMouseMove()
{
    sheet.mouseMove(Ogre::Vector2(x, y));
}
// etc.

advantages:
- not slow
- clean
- simple
- very boost-based (extremely flexible)
- names are automatically fixed if overlapping: creating multiple widgets with the name "widget" will result in the following list:
widget, widget_0, widget_1, widget_2, widget_3, etc. (the '_' denotes a copy, and the number after it is the copy index)
- no GUI managers or anything, just create the widget hierarchy as you see fit
- you can have as many sheets and whatever as you wish; this allows easy integration for in-game monitors, etc:

Code: Select all

void game::monitor::render()
{
    _sheet->render(_viewport); // _viewport could be for the in-game monitor's RTT
}

- easy to create custom widgets (just inherit and do stuff)
- widgets can rotate, scale, deform, use shaders, anything really since it's all custom rendering
- can render anytime, anywhere

disadvantages:
- not fast
- not loads of functionality yet (no competition in this department with QuickGUI or CEGUI or MyGUI or what-not)
- no skinset editing, etc. (mainly a programmer's GUI, nothing overly fancy)
- requires boost (more like an advantage for those who don't have boost installed, it'll force them to install it )

Just to reiterate due to an overload of comments above:

Code: Select all

// all that is needed for a proper GUI that has a draggable panel that displays a gbuffer texture

gui::sheet sheet("sheet");

gui::panel img("img");
img->textureName("gbuffer_0)";
img->size(Ogre::Vector2(196, 196));

sheet->addChild(img);

render loop
{
    sheet.render(viewport);
}

[KungFooMasta]

Ah, I was hoping it was some 3d GUI library that makes meshes and/or submeshes into buttons and handles changing of materials transparently..

I agree that a lot of GUIManager functionality could be combined with a Sheet. The only benefit I can think of at the moment is being able to switch in and out sheets for rendering. Easily done with your sheet method, also.

If you decide to develop this further you should look at the skinning system I setup, its really simple, portable, and manageable for programmers, artists, anybody really.

[nullsquared]

I agree that a lot of GUIManager functionality could be combined with a Sheet. The only benefit I can think of at the moment is being able to switch in and out sheets for rendering. Easily done with your sheet method, also.

Right, I just decided to go for a completely new design from all of the other GUIs out there. Each and every one of them require some sort of central manager. And you can never just create your own widget and add it as a child, it's always done through functions like createWindow(), createThis(), createThat(), etc.

The big problem here was that there was only 1 GUI manager, and it had to be passed around from place to place (I'm a dependency freak, singletons make me cringe) just to create a widget hierarchy. With this new design, the GUI is completely independent. You need a GUI? Create a master widget, create child widgets, attach them, and just render the master widget. A sheet is just another widget, but it doesn't draw itself. Heck, if you wanted to, you could create a child widget and manually render it yourself with the same render() call.

As for the sheet switching. Technically, every different state should have its own sheet. Meaning - an in game monitor would have a sheet, the editor state would have a sheet, the gameplay state would have a sheet, the main menu state, etc. Since these sheets are owned by the states themselves, I decided to thus completely drop the GUI manager idea. No need for an extra layer of indirection if you already have what you're going to render

Of course, nothing against your or anyone else's design I still love QuickGUI and BetaGUI, but considering everyone's joining the GUI bandwagon and I wanted a bit of my own solution, hey

If you decide to develop this further you should look at the skinning system I setup, its really simple, portable, and manageable for programmers, artists, anybody really.

Will do. Lots of ideas are borrowed from QuickGUI (cough, sheet ), I give you many kudos and a piece of my bread.

[Glajan]

I use SlickEdit (in Emacs mode) with with the default theme.

edit:
.. and Code::Blocks with the default theme.

[nikki]

Since a few people posted screenshots, I thought I'd do that too. Here's mine:-



Yes, I like hacks. Especially my 'GlbVar' one. Its dirty, but I like it.

[volca]

I like that, it's nice and clean... What's the DM and Editor?
I would guess editor is GVim (Cream?), and the environment is fvwm or blackbox but am not sure

[nikki]

I like that, it's nice and clean... What's the DM and Editor?
I would guess editor is GVim (Cream?), and the environment is fvwm or blackbox but am not sure

The editor is gvim, with loads of plugins, and the environment is xmonad with dzen. I use conky to send all that stuff to dzen.

EDIT: betajaen, 'n:\bloodymess'?

[KungFooMasta]

nullsquared, I was considering doing the same and integrating my GUIManager functionality with my Sheet, but I had a question: what do you do about the MouseCursor? Do you only have 1 cursor on the screen, or one per sheet? Wouldn't that look odd to see a TV screen with a mouse cursor sitting there? Whats the ideal scenario if you have 3d UI Sheets around the scene, in relation to cursor positioning and interaction?

Also, the reason I have the createXXX methods is to be explicit about allowing what types of widgets I support. For example, allowing users to add a TitleBar to a Button, or a ScrollBar on a CheckBox seems really silly.

[betajaen]

EDIT: betajafen, 'n:\bloodymess'?

Next codename of NxOgre 1.1


@KungFooMasta and @Nullsquared

A few months ago, I started on some early (prototype - no code) work on a new GUI concept called Chocolate. The idea was it would be built around the web-page model; everything could be in everything else, and everything has events. There were no fixed roles for things; no concept of buttons or text input boxes, no images and so on.

A collection of "things" was built like a document in practice and in code; no createXXX methods just a lot of chaining functions.

Code: Select all

Chocolate* chocolate = new Chocolate();

chocolate->division(
 "Hello",
 _with
  << _size(100)
  << _position(_position::Center)
  << "<>Hello world!\nHow are you?\n"
  << _division(
      "Okay",
      _with
           << _is(_is::ParentEnterAction, _is::ParentEscapeAction)
           << _when(_onClick, _closeParent)
       )
);

I would like to say I completed it; but it's still an empty header shell. But I want to finish it one day.

[nikki]

EDIT: betajafen, 'n:\bloodymess'?

Next codename of NxOgre 1.1

You can't be British (or Scottish, or whatever, I'm bad at this stuff) and not have the word 'bloody' somewhere in your computer, eh?

[betajaen]

I'm Welsh, I was born in Wales but I'm also British.

Of course you can have "Bloody" in a name, the current NxOgre branch is called "Bleeding Edge", it would make sense that the next release would be Blood related.

[nullsquared]

nullsquared, I was considering doing the same and integrating my GUIManager functionality with my Sheet, but I had a question: what do you do about the MouseCursor? Do you only have 1 cursor on the screen, or one per sheet?

One per sheet. The sheet "is" your GUI, and obviously each GUI needs a mouse. If it doesn't, then... well:

Code: Select all

sheet->mouse()->visible = false;

[nikki]

Of course you can have "Bloody" in a name, the current NxOgre branch is called "Bleeding Edge", it would make sense that the next release would be Blood related.

All this 'bloody' stuff reminds me of the Demoman.

[nullsquared]

EDIT: betajafen, 'n:\bloodymess'?

Next codename of NxOgre 1.1


@KungFooMasta and @Nullsquared

A few months ago, I started on some early (prototype - no code) work on a new GUI concept called Chocolate. The idea was it would be built around the web-page model; everything could be in everything else, and everything has events. There were no fixed roles for things; no concept of buttons or text input boxes, no images and so on.

A collection of "things" was built like a document in practice and in code; no createXXX methods just a lot of chaining functions.

Code: Select all

Chocolate* chocolate = new Chocolate();

chocolate->division(
 "Hello",
 _with
  << _size(100)
  << _position(_position::Center)
  << "<>Hello world!\nHow are you?\n"
  << _division(
      "Okay",
      _with
           << _is(_is::ParentEnterAction, _is::ParentEscapeAction)
           << _when(_onClick, _closeParent)
       )
);

I would like to say I completed it; but it's still an empty header shell. But I want to finish it one day.

That's actually very interesting. Quick prototype of what it might look like (kind of):

Code: Select all

widget a("a");

    a << position(2, 2) << size(2, 2) << text("hi") <<
    (
        widget("b") << position(3, 3) << text("hi") << size(2, 2)
    ) <<
    (
        widget("c") <<
        (
            widget("d") << position(4, 4)
        )
    );

Output:

Code: Select all

widget "a"
{
        p : 2 2
        s : 2 2
        t : hi
        children:
        widget "b"
        {
                p : 3 3
                s : 2 2
                t : hi
                children:
        }
        widget "c"
        {
                p : 0 0
                s : 0 0
                t :
                children:
                widget "d"
                {
                        p : 4 4
                        s : 0 0
                        t :
                        children:
                }
        }
}