New comer on QuickGui

zolt4n

04-12-2007 11:23:53

Hello
I'm a new comer on QuickGui And I have lot of problem :(

first Thx to developer it's easy to use.

So I done a window and a button in my window
I done that

set parent(name = Parent Name)
{
_widget->setHideWithParent(true);
_widget->setInheritClippingWidget(true);
_widget->setInheritOpacity(true);
_widget->setInheritQuadLayer(true);
_widget->appearOverWidget(_labelsMap[name]);
}

addChild(name = child name)
{
_widget->setDraggingWidget(_labelsMap[name]);
_widget->addChild(_labelsMap[name]);
}


but when I move my dragable windows this fucking child don't move, And when I move the child the child is not clipped with this parent ....
It's not implemented or I'm not lucky


An other problem
if I create a combobox
I Have a segfault if text finished by an space
in this lines : _setCaptionHorizontal("le TExt ");
the last space is the cause of the segfault.

I have fix this bug with this line
if(mTextHelper->isSpace(cp) && (it+1) != text.end())

I think that i found only this problem, thanx you for anwser

zolt4n

04-12-2007 12:13:36

I have put some debug printing in this method
void Widget::addChild(Widget* w)

and I can see that
_widget->addChild(_labelsMap[name]);
don't call this function ????

I don't understand because my method is call
(check with breakpoint)

picture prove it


in fact I found that

void Panel::addChild(Widget* w)
{
if(w->getParentWidget() != NULL)
return;

is called and the first if break from method but I don't have any parent ??
answer : It's because when I create my QuickGui::combobox I made mSheet->createComboBox(name);
so it's parent is 'Sheet1' Beug ? or bad code ???

kungfoomasta

04-12-2007 17:33:00

I believe you have to call Widget::setDraggingEnabled(true) in order to allow dragging. Setting the Dragging Widget specifies what widget to drag. For example, a TitleBar drags its parent, the Window.

I will look into the error with a space, when I get a chance. Thanks for posting this.


void Panel::addChild(Widget* w)
{
if(w->getParentWidget() != NULL)
return;


If the widget w is already a child of another widget, it cannot be added. This is similar to SceneNodes, you can't have a SceneNode have 2 parents!

hotdot

04-12-2007 18:04:12

Question zolt4n are you french ? and nothiced your name was zoltan is it related to that cheap movie revolving on the dog of dracula :P that movie is so hilarious !!!

zolt4n

05-12-2007 12:18:01

Yep I'm french (You know that because of my bad english ???)
else yep zoltan (my nickname is from Dude where ismy car in french hé mec elle est ou ma caisse ) but it's not very important...


I'm developpind a widget Tree using existing list but I have bug and segfault.

segfault in void ScrollPane::scrollIntoView(Widget* w) >> when I don't allowscrooling in this line
if(mManagedWidgets.find(w) == mManagedWidgets.end())

and a bug when my list is not anought big Menulabels are visible and not in the list ...

hotdot

05-12-2007 14:19:36

nice to see fellow frenchman, i noticed from your example the "maintenant" word is quite incriminating and "le Texte" :)

We will have to wait for KungFooMasta's response to this i never had this error, but you will have to wait a bit cause hes fixing the renderer for directx, so it may not be before the end of the week (hes working hard this week so we should be lax a bit).

Have you traced the code ?

if you want to private message me in french i can relay the info more clearly also as an alternative, i do not really understand :

and a bug when my list is not anought big Menulabels are visible and not in the list ...

kungfoomasta

05-12-2007 17:42:03

I believe the only way the first bug can occur is if ScrollPane is NULL, and my code is trying to call NULL->scrollIntoView(...). I will look into that, should be a simple gaurd statement.

and a bug when my list is not anought big Menulabels are visible and not in the list ...

Can you show a screenshot? (I'm having trouble understanding what is happening)

zolt4n

05-12-2007 21:18:56

OK so this is the screenshoots

list OK :


list Bad :


You can see that MenuLabel are not in the list but I think that is cause by my fault (I had coment code who checked if they has already a parent)

I will see tomorrow for the segfault and this bug
Thx U.

kungfoomasta

05-12-2007 23:34:39

It looks like the text is not clipping correctly. But in the first screenshot, it does clip correctly. :? So what are the differences between each instance? If you can give me code to reproduce this I could look into it, but if you are looking into it, that would be great also, and give me time to work on the Render work. :)

zolt4n

06-12-2007 11:17:25

Sorry I forget to say that the second list is in a window , it's the only one difference

kungfoomasta

06-12-2007 17:36:24

I'll see if I can repro this in the demo, when I get a chance. Its a really busy month for me!

zolt4n

06-12-2007 19:29:11

IT's very IMPORTANT


change this


void ScrollPane::scrollIntoView(Widget* w)
{
if(mManagedWidgets.find(w) == mManagedWidgets.end())
return;

by this


void ScrollPane::scrollIntoView(Widget* w)
{
if(!mManagedWidgets.size() || mManagedWidgets.find(w) == mManagedWidgets.end())
return;



that was causing a segfault !!!

hotdot

06-12-2007 20:58:21

lol, defense !

kungfoomasta

06-12-2007 22:20:45

Is that seriously the bug???

I would think the std::map::find function can handle an empty map! :shock:

I will add it in, it couldn't hurt, but I'm surprised..

Zini

06-12-2007 22:39:22

std::map::find can handle an empty map. If you get a segfault, the problem must be something else (assuming you don't have a broken STL-implementation). I would like to remember you again, that we had a similar problem recently (heap corruption or something), which hasn't been solved. And if I haven't missed something, this bug:

http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=5859

hasn't been fixed yet, which means every single program using QuickGUI will corrupt its heap at some point. No idea, if it is related in any way, but it should be enough to start getting nervous.

kungfoomasta

06-12-2007 23:05:26

Thanks for reminding me. I looked over the code and posted on that thread, hopefully the fix is as simple as I suggest..

hotdot

06-12-2007 23:06:13

As a matter of fact raising this again is a good thing because one thing that as striken me is the fact that you cannot add new system widgets in any way except by compositing them, probably the design is made to be like that but i am arguing that the Widgets should be more open and not created by Sheets or Windows, think like the .NET framework, its not the window that creates a radio button. If we could simply add pointers and have more adapter patterns and Observer patterns in there everything should probably be better, and the memory corruption would be passed on to the user of the widget instead of the widget system itself. Trying to limit too much the scope of functionality here is great for newbies, but i am getting more and more to a point where the gui system will need to be branched by all users to get where projects need to go. The best way would be to rethink the whole architecture, it could be clearer. Maybe there is a constraint somewhere that make things the way they are.

Just my two cents, maybe im wrong, but i have been thinking about branching stuff, or make a new level of abstraction.

Zini

06-12-2007 23:15:30

Even though I agree that a different approach to widget creating/destruction would make things slightly more flexible, what you are proposing is a rewrite of pretty much all of QuickGUI, except for the render system maybe (if I understand you correctly). Since this would make it a totally different GUI library I am not in favor of it.

kungfoomasta

06-12-2007 23:24:54

Before you argue about the flexibility of the widgets, I would like to hear some concrete examples of widgets that you think would surpass my idea of a combination of existing widgets.

As a matter of fact I am thinking .NET, in terms of a large pre-defined widget set available for users to make easy applications with. If you want the ability to hand code the functionality of all your widgets in script or XML, I think that is similar to CEGUI's LookNFeel, or some other configuration file, since CEGUI uses many.

On one side there is the voice of "there are so many things to maintain, so many options and I don't know what to do with them". On the other side, there is "it isn't open enough, I want to be able to do anything I want". I find this to be a contradiction in ideas. Easier said than done. :wink:

I personally don't see a need to rethink the architecture. :P