libufo-devel — Discussion forum for users and developers

Re: [UFO-devel] UBasicStyle::paintComponent() crash

[Johannes S. <sch...@us...>]

Am Donnerstag 14 Juli 2005 01:08 schrieb Andreas Beckermann:
> Hi
> UBasicStyle::paintComponent() uses NULL as default value for its w
> parameter, but never checks for it being NULL.
> This causes a crash for CE_TextEdit at line 799 ("w->getPalette()").
>
> At a very least the method should check w before that line.

Thanks.
The correct way is to use the style hints object
(which is how I have changed it).
Fix should be in CVS.


Regards,
Johannes

[UFO-devel] UBasicStyle::paintComponent() crash

[Andreas B. <b_...@gm...>]

Hi
UBasicStyle::paintComponent() uses NULL as default value for its w parameter, 
but never checks for it being NULL.
This causes a crash for CE_TextEdit at line 799 ("w->getPalette()").

At a very least the method should check w before that line.

CU
Andi

[UFO-devel] compile error

[Andreas B. <b_...@gm...>]

Hi
current cvs: udocumentfactory.hpp includes udocumentfilter.hpp (and uses 
classes from it) which is gone.

It looks like the header wasn't committed after changing it

CU
Andi

Re: [UFO-devel] Compiling for FreeBSD

[satanman <sat...@ma...>]

> ----- Original Message -----
> From: "Johannes Schmidt" <sch...@us...>
> To: lib...@li...
> Sent: Tuesday, July 12, 2005 02:02 PM
> Subject: [UFO-devel] Compiling for FreeBSD
 
> Hmm, as there are too many bugs with USharedPtr for virtual UFontRenderer,
> I have replaced it in ufont.cpp with raw reference counting.
 
> Please try the current snapshot (http://libufo.sf.net/snapshots/) or
> the CVS version.
 
> Regards,
> Johannes

it works :D

thanks.

oh, and in case you didn't notice, I don't use mailing lists, or in fact email, very much; I prefer to use IRC, IM, forums and the like, so sorry if I'm missing some standard practice or such...

Visit http://www.thegaminguniverse.com for all your game (re)making needs.
Get your own Gaming Universe email at http://mail.thegaminguniverse.com.

Re: [UFO-devel] Compiling for FreeBSD

[Johannes S. <sch...@us...>]

Am Montag 11 Juli 2005 16:27 schrieb satanman:
> hi,
>
> When compiling for FreeBSD 5.4, I get this coming up (./configure runs
> fine)
>
>
> Making all in include
> Making all in src
[...]
> font/.deps/ufont.Tpo -c font/ufont.cpp  -fPIC -DPIC -o font/.libs/ufont.o
> /usr/include/c++/3.4/bits/stl_map.h: In member function `_Tp&
> std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with _Key =
> ufo::UFontInfo, _Tp = ufo::USharedPtr<ufo::UFontRenderer>, _Compare =
> std::less<ufo::UFontInfo>, _Alloc = std::allocator<std::pair<const
> ufo::UFontInfo, ufo::USharedPtr<ufo::UFontRenderer> > >]':
> font/ufont.cpp:106:   instantiated from here
> /usr/include/c++/3.4/bits/stl_map.h:339: error: no matching function for
> call to
> `ufo::USharedPtr<ufo::UFontRenderer>::USharedPtr(ufo::USharedPtr<ufo::UFont
>Renderer>)' *** Error code 1
>
[...]

Hmm, as there are too many bugs with USharedPtr for virtual UFontRenderer,
I have replaced it in ufont.cpp with raw reference counting.

Please try the current snapshot (http://libufo.sf.net/snapshots/) or
the CVS version.

Regards,
Johannes

Re: [UFO-devel] Widget events not fired?

[Johannes S. <sch...@us...>]

Am Samstag 09 Juli 2005 15:32 schrieb Mark Robson:
> I'm using the CVS snapshot ufo-20050707.tar.gz
>
> I've built the example "internalframe", and none of the widget events
> appear to be fired at all, even when the frame is moved, resized and
> closed.

Thanks.
Should be fixed in CVS resp. the current snapshot 
(http://libufo.sf.net/snapshots/).

Regards,
Johannes

[UFO-devel] Compiling for FreeBSD

[satanman <sat...@ma...>]

hi,

When compiling for FreeBSD 5.4, I get this coming up (./configure runs fine)


Making all in include
Making all in src
depbase=`echo font/ufont.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;  if /usr/local/bin/bash ../libtool --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -DUFO_BUILDING_DLL  -I. -I. -I../include/ufo/config      -g -O2  -I/usr/X11R6/include -DUFO_TARGET_OPENGL -DTIXML_USE_STL -I../include/ufo/xml -I../include -MT font/ufont.lo -MD -MP -MF "$depbase.Tpo" -c -o font/ufont.lo font/ufont.cpp;  then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -DUFO_BUILDING_DLL -I. -I. -I../include/ufo/config -g -O2 -I/usr/X11R6/include -DUFO_TARGET_OPENGL -DTIXML_USE_STL -I../include/ufo/xml -I../include -MT font/ufont.lo -MD -MP -MF font/.deps/ufont.Tpo -c font/ufont.cpp  -fPIC -DPIC -o font/.libs/ufont.o
/usr/include/c++/3.4/bits/stl_map.h: In member function `_Tp& std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const _Key&) [with _Key = ufo::UFontInfo, _Tp = ufo::USharedPtr<ufo::UFontRenderer>, _Compare = std::less<ufo::UFontInfo>, _Alloc = std::allocator<std::pair<const ufo::UFontInfo, ufo::USharedPtr<ufo::UFontRenderer> > >]':
font/ufont.cpp:106:   instantiated from here
/usr/include/c++/3.4/bits/stl_map.h:339: error: no matching function for call to `ufo::USharedPtr<ufo::UFontRenderer>::USharedPtr(ufo::USharedPtr<ufo::UFontRenderer>)'
*** Error code 1

Stop in /home/chris/ufo-0.8.0/src.
*** Error code 1

Stop in /home/chris/ufo-0.8.0.

It looks like somewhere you've tried to construrct a USharedPtr using a copy constructor, and it doesn't beieve that exists or something...

I'm using the most recent snapshot (2005-07-07)

Visit http://www.thegaminguniverse.com for all your game (re)making needs.
Get your own Gaming Universe email at http://mail.thegaminguniverse.com.

[UFO-devel] Widget events not fired?

[Mark R. <ma...@gm...>]

I'm using the CVS snapshot ufo-20050707.tar.gz

I've built the example "internalframe", and none of the widget events
appear to be fired at all, even when the frame is moved, resized and
closed.

Mark

Re: [UFO-devel] Can't set a font

[Mark R. <ma...@gm...>]

> Well, there aren't many fonts you can actually select.
> There is only the builtin font renderer which has:
> sans-serif font with point size 10,12
> serif font with point size 10
> mono spaced font with point size 8

I have seen this in the source now.

> Furthermore, in older releases there was an X11/GLX font renderer
> which can use all fonts visible to your X server.
> If you are interested, I can fix it for current releases.

No, that is not important. I  am more interested in the textured
fonts, especially if I have the program to create custom ones.

This will enable me to use fonts not present on the user's machine. It
would also be nice if my program uses the same fonts on Windows and
Linux.

> > Also, I tried to use texture fonts setting UFO_FONT and UFO_FONT_DIR,
> > but the appearance is very poor (labels don't work at all, and buttons
> > appear with the text displaced and off-centre). Is this a known bug?
>=20
> Hmm, I thought that I have already fixed this ...

You may have already fixed this. I'm now using a different version of
UFO, the cvs snapshot 20050707.

I can't get texture fonts to work at all with this version, setting
UFO_FONT and UFO_FONT_DIR appears to have no effect whatsoever (it
still uses built in fonts).

Good luck with your exams.

I am going to make a game which uses UFO - it will have an opengl part
rendered in (almost) 3d, and some popup windows (UInternalFrame
probably) which can be rendered using UFO.

I've done some experiments, and I've now got that to work, provided I
can perusade UFO to stop drawing the background over my opengl
graphics (which now works)

Mark

Re: [UFO-devel] Can't set a font

[Johannes S. <sch...@us...>]

On Friday 08 July 2005 19:39, Mark Robson wrote:
> I've got a CVS snapshot,  ufo-20050621.tar.gz
>
> This seems to work a lot better, at least I can set the font without
> it crashing. However, no font settings I make seem to make any
> difference.

Well, there aren't many fonts you can actually select.
There is only the builtin font renderer which has:
sans-serif font with point size 10,12
serif font with point size 10
mono spaced font with point size 8

and three textured fonts.

Furthermore, in older releases there was an X11/GLX font renderer
which can use all fonts visible to your X server.
If you are interested, I can fix it for current releases.

> Could you suggest a method to determine what fonts are available.

UToolkit->listFonts() should work ...
ATM, I am making some internal changes to font handling
so it might be broken ...

> Also, I tried to use texture fonts setting UFO_FONT and UFO_FONT_DIR,
> but the appearance is very poor (labels don't work at all, and buttons
> appear with the text displaced and off-centre). Is this a known bug?

Hmm, I thought that I have already fixed this ...

Possible values for UFO_FONT are:
builtin_font
gl_texture_font
texture_font

> Is there any reasonable way which I can set a custom font without
> writing my own font renderer?
>
> You have provided three font files, Arial_10.tga etc. Have you got the
> source code of the program which created these? Did it use Freetype or
> something to convert Truetype fonts? If so, can I have it so that I
> can use custom fonts in my app?

The texture fonts are created via UFO, SDL_ttf and truetype fonts.
The builtin fonts are created using plain X11.

I can give you source code and binaries.
Please be patient for one or two weeks as I have to pass
some important exams next week.


Regards,
Johannes

Re: [UFO-devel] Can't set a font

[Mark R. <ma...@gm...>]

I've got a CVS snapshot,  ufo-20050621.tar.gz

This seems to work a lot better, at least I can set the font without
it crashing. However, no font settings I make seem to make any
difference.

Could you suggest a method to determine what fonts are available.

Also, I tried to use texture fonts setting UFO_FONT and UFO_FONT_DIR,
but the appearance is very poor (labels don't work at all, and buttons
appear with the text displaced and off-centre). Is this a known bug?

Is there any reasonable way which I can set a custom font without
writing my own font renderer?

You have provided three font files, Arial_10.tga etc. Have you got the
source code of the program which created these? Did it use Freetype or
something to convert Truetype fonts? If so, can I have it so that I
can use custom fonts in my app?

Cheers

Mark

Re: [UFO-devel] Can't set a font

[Johannes S. <sch...@us...>]

Hi,

Am Mittwoch 06 Juli 2005 22:00 schrieb Mark Robson:
> I am very impressed with the quality of this library, but very
> unimpressed with the quality of the documentation.
>
> Specifically, there is no overview as to how to use the library
> generally - although the examples helped, it seems they did not call
> every thing.
>
> I don't understand how the garbage collection works - I'll assume for
> the time being that it just does.
>
> Anyway, I'm trying to set the font of a widget (ULabel) to something
> other than the default, but it crashes almost immediately afterwards.
>
> I've modified the "layouts" example, and I've tried putting the
> ->setFont in various different places, but it makes little difference.
>
> I'm doing something like
>
>         label->setFont(new UFont(UFontInfo::SansSerif, 16));
>
> at about line 151 of layouts.cpp

[...]
> What am I doing wrong? I am using libufo 0.7.4 on Linux with OpenGL
> and the Nvidia drivers - other opengl applications work fine.

There seems to be a serious bug with setting fonts in 0.7.4.
Possibly the font is destructed by the graphics object ...?

Well, I haven't used 0.7.4 for weeks, as I am working on the new
0.8.0 release. Setting fonts with this release should work
(it uses objects created on the stack, no pointers).

Unfortunately, this release is delayed until the end of the semester
(have to write several exams) which is ca. Mid July.

Perhaps you want to try one of the snapshots from
http://libufo.sourceforge.net/snapshots/

Regards,
Johannes

[UFO-devel] Can't set a font

[Mark R. <ma...@gm...>]

Hi there,

I am very impressed with the quality of this library, but very
unimpressed with the quality of the documentation.

Specifically, there is no overview as to how to use the library
generally - although the examples helped, it seems they did not call
every thing.

I don't understand how the garbage collection works - I'll assume for
the time being that it just does.

Anyway, I'm trying to set the font of a widget (ULabel) to something
other than the default, but it crashes almost immediately afterwards.

I've modified the "layouts" example, and I've tried putting the
->setFont in various different places, but it makes little difference.

I'm doing something like

        label->setFont(new UFont(UFontInfo::SansSerif, 16));

at about line 151 of layouts.cpp

And it's crashing somewhere like:

Program received signal SIGSEGV, Segmentation fault.
0xb7f01b5c in ufo::UGL_Graphics::setFont (this=3D0x80c6e38,
font=3D0xb7d618a0) at ucollectable.hpp:80
80      UCollectable::reference() const { m_refCount++; }
(gdb) bt
#0  0xb7f01b5c in ufo::UGL_Graphics::setFont (this=3D0x80c6e38,
font=3D0xb7d618a0) at ucollectable.hpp:80
#1  0xb7f92076 in ufo::UWidget::paint (this=3D0x812d1f8, g=3D0x80c6e38) at
widgets/uwidget.cpp:543
#2  0xb7f922e9 in ufo::UWidget::paintChildren (this=3D0x812ac88,
g=3D0x80c6e38) at stl_iterator.h:149
#3  0xb7f92094 in ufo::UWidget::paint (this=3D0x812ac88, g=3D0x80c6e38) at
widgets/uwidget.cpp:546
#4  0xb7f922e9 in ufo::UWidget::paintChildren (this=3D0x81080a8,
g=3D0x80c6e38) at stl_iterator.h:149
#5  0xb7f92094 in ufo::UWidget::paint (this=3D0x81080a8, g=3D0x80c6e38) at
widgets/uwidget.cpp:546
#6  0xb7f922e9 in ufo::UWidget::paintChildren (this=3D0x8107f10,
g=3D0x80c6e38) at stl_iterator.h:149
#7  0xb7f92094 in ufo::UWidget::paint (this=3D0x8107f10, g=3D0x80c6e38) at
widgets/uwidget.cpp:546
#8  0xb7f922e9 in ufo::UWidget::paintChildren (this=3D0x80e3ea0,
g=3D0x80c6e38) at stl_iterator.h:149
#9  0xb7f92094 in ufo::UWidget::paint (this=3D0x80e3ea0, g=3D0x80c6e38) at
widgets/uwidget.cpp:546
#10 0xb7f5f619 in ufo::UXContext::repaint (this=3D0x80cf1c8) at
ux/uxcontext.cpp:128
#11 0xb7f63347 in ufo::UXFrame::repaint (this=3D0x80574a8, force=3Dfalse)
at ux/uxframe.cpp:115
#12 0x0804a98e in main (argc=3D1, argv=3D0xbffffb84) at layouts.cpp:52

HOWEVER, the funny thing is, just before it crashes, it does actually
appear to render that label in a different font from the rest of the
app (this is only visible if it's stopped in the debugger after the
crash, otherwise the window vanishes immediately)

What am I doing wrong? I am using libufo 0.7.4 on Linux with OpenGL
and the Nvidia drivers - other opengl applications work fine.

Mark

Re: [UFO-devel] URadioButton::setSelected()

[Johannes S. <sch...@us...>]

Am Sonntag 26 Juni 2005 16:52 schrieb Andreas Beckermann:
> Hi
> 1. create a UButtonGroup
> 2. create two URadioButton widgets
> 3. add both buttons to the button group
> 4. call URadioButton::setSelected(true) on one of the two buttons
> -> the UButtonGroup is out of sync. The radio button is displayed as being
> selected, but the button group has no selected button.

Thanks. Should be fixed in CVS.

Regards,
Johannes

[UFO-devel] URadioButton::setSelected()

[Andreas B. <b_...@gm...>]

Hi
1. create a UButtonGroup
2. create two URadioButton widgets
3. add both buttons to the button group
4. call URadioButton::setSelected(true) on one of the two buttons
-> the UButtonGroup is out of sync. The radio button is displayed as being 
selected, but the button group has no selected button.

I tested with a pretty old version (the libufo copy that we use in boson cvs. 
still not updated because most of my patches never made it to offical cvs, so 
updating is a lot of work for me). However from looking at the current CVS 
code, I believe the bug should still happen, as the button group is updated 
in UButton::activate(), which is not called by UButton::setSelected().

Why are signals/slots not used for this?

CU
Andi

Re: [UFO-devel] new snapshot

[Johannes S. <sch...@us...>]

Am Mittwoch 22 Juni 2005 13:47 schrieb Johannes Schmidt:
> I have uploaded a new snapshot of the upcoming 0.8.0 release.
>
> http://libufo.sourceforge.net/snapshots/ufo-20050621.tar.gz

The xul example (test/xul.cpp) is missing a "frame->setVisible(true);"
e.g. in line 38.


Regards,
Johannes

Re: [UFO-devel] new snapshot

[Johannes S. <sch...@us...>]

Am Mittwoch 22 Juni 2005 17:32 schrieb Andreas Beckermann:
> > I have uploaded a new snapshot of the upcoming 0.8.0 release.
>
> [...]
>
> Looking at the current cvs version this snapshot is more recent than cvs.
> Why?
>
> Is there a reason for why CVS is not the current development version? Which
> _is_ the most current version anyway usually?
> Or did anonymous CVS just not catch the changes yet?

Probably (viewCVS shows an old version, too).

Actually the snapshot should have 2005-06-22 as date, since I made
some commits just before creating this snapshot
(didn't want to re-send the message ...).

But CVS/HEAD and the snapshot source should be the same.


Regards,
Johannes

Re: [UFO-devel] new snapshot

[Andreas B. <b_...@gm...>]

On Wednesday 22 June 2005 13:47, Johannes Schmidt wrote:
> Hi,
>
> I have uploaded a new snapshot of the upcoming 0.8.0 release.
[...]

Looking at the current cvs version this snapshot is more recent than cvs. Why?

Is there a reason for why CVS is not the current development version? Which 
_is_ the most current version anyway usually?
Or did anonymous CVS just not catch the changes yet?

CU
Andi

[UFO-devel] new snapshot

[Johannes S. <sch...@us...>]

Hi,

I have uploaded a new snapshot of the upcoming 0.8.0 release.

http://libufo.sourceforge.net/snapshots/ufo-20050621.tar.gz

Major changes since last snapshot:
  * Implemented keyboard control for menus and buttons
  * Added new shortcut API for widgets:
     UWidget::grab,releaseShortcut(UKeyStroke&);
     If a shortcut was grabbed and pressed by the user, the widget gets
     UShortcutEvents (override processShortcutEvent(UShortcutEvent*));
  * Fixed accelerator and mnemonic support for buttons and menus.
  * Implemented enabled-property for several widgets
  * Added UGroupBox
  * Added UShortcutEvent
  * Changed isVisible to return the actual mapping status (i.e.
     if all parents and the given widget are visible).
  * Changed setEnabled to disable implicitly all child widgets (re-enabling
     enables them again).

See test/buttons.cpp and test/menus.cpp.

This will be the last snapshot, as I am going to release 0.8.0 soon (hopefully 
next weekend).

A detailed description what happened since 0.7.4 will follow.

Some patches are still missing. They will be added in the next micro release 
(0.8.1).

Enjoy,
Johannes

Re: Visible/Enabled (Was: Re: [UFO-devel] Accelerators)

[Johannes S. <sch...@us...>]

Am Montag 13 Juni 2005 18:52 schrieb Andreas Beckermann:
> On Monday 13 June 2005 17:37, Johannes Schmidt wrote:
> > Let me quote http://doc.trolltech.com/4.0/qwidget.html#enabled-prop:
> > "Disabling a widget implicitly disables all its children. Enabling
> > respectively enables all child widgets unless they have been explicitly
> > disabled."
> >
> > As for the visible property:
> > In my last E-Mail I wrote that the intention is to get an easy way for
> > querying whether a widget is mapped to screen.
> > The user behaviour for setVisible remains the same (i.e. if you call
> > setVisible(false) on a widget, it remains invisible even if the
> > parent widget becomes visible).
>
> Ah, so actually you do _not_ intend to change the behaviour of
> setVisible()/setEnabled() (that is what you wrote in the beginning!). You
> want to change isVisible() and isEnabled() only 

Ouch, sorry, misunderstanding.
Yes, setVisible should do the same thing, it's just a change to
the internal handling (and what the is*() methods return).

> - well I don't really care about that :-)

Okay, then I will change that.
I am happy that the communication works (even though it may take some time :)


Regards,
Johannes

Re: Visible/Enabled (Was: Re: [UFO-devel] Accelerators)

[Andreas B. <b_...@gm...>]

On Monday 13 June 2005 17:37, Johannes Schmidt wrote:
[...]
> Let me quote http://doc.trolltech.com/4.0/qwidget.html#enabled-prop:
> "Disabling a widget implicitly disables all its children. Enabling
> respectively enables all child widgets unless they have been explicitly
> disabled."
>
> As for the visible property:
> In my last E-Mail I wrote that the intention is to get an easy way for
> querying whether a widget is mapped to screen.
> The user behaviour for setVisible remains the same (i.e. if you call
> setVisible(false) on a widget, it remains invisible even if the
> parent widget becomes visible).

Ah, so actually you do _not_ intend to change the behaviour of 
setVisible()/setEnabled() (that is what you wrote in the beginning!). You 
want to change isVisible() and isEnabled() only - well I don't really care 
about that :-)

To me it is very important that
  widget->setVisible(true);
  parentOfWidget->setVisible(false);
hides both widgets and
  parentOfWidget->setVisible(true);
makes both of them visible again, whereas
  parentOfWidget->setVisible(false);
  widget->setVisible(false);
  parentOfWidget->setVisible(true);
makes the parentOfWidget visible only, while widget remains hidden.
Therefore I vote strongly against changing setVisible() in the way that I have 
shown in my last mail, as it makes setVisible() essentially useless to me 
(and anyone else who wants to create non-trivial GUIs).

btw: the lack of the described behaviour in plib is one of the reasons why I 
am using libufo :-)

> Regards,
> Johannes

CU
Andi

Re: Visible/Enabled (Was: Re: [UFO-devel] Accelerators)

[Johannes S. <sch...@us...>]

Am Sonntag 12 Juni 2005 16:26 schrieb Andreas Beckermann:
> On Friday 10 June 2005 13:01, Johannes Schmidt wrote:
> > Am Freitag 10 Juni 2005 12:04 schrieb Andreas Beckermann:
> > > On Friday 10 June 2005 10:57, Johannes Schmidt wrote:
> > > [...]
> > >
> > > > Secondly, I am pondering about a changing the behaviour of
> > > > setVisible and setEnabled.
> > >
> > > Which change are you talking about?
> >
> > The change which was described below, especially when following the
> > links.
>
> I still don't see which change you mean
> The docs that you quoted state pretty much the current behaviour of libufo,
> except for the fact that the enabled property of libufo is mostly ignored
> currently.
> [...]
>
> > > > IMHO, hiding all child widgets when calling setVisible(false) is
> > > > reasonable.
> > >
> > > See above. If you mean by "hiding" not to show them, I agree. If you
> > > mean by it calling setVisible(false) on them, I disagree.
> >
> > Well, as you always favor the way of QT, I thought that you'd like it.
> > As described in the given APi docs, there should be some sort of
> > force_invisible. But you could also introduce some new methods.
>
> Really, I still fail to see your point, please explain further what you
> mean. Do you really want to make the behaviour of setVisible() turn into
> this: void UWidget::setVisible(bool e)
> {
>  m_isVisible = e;
>  for (all children) {
>     child->setVisible(e);
>  }
> }
> ?
>
> If so, then I think that is a _really_ bad idea. btw: Qt does _not_ do
> that. In Qt setVisible(false) actually _does_ hide all children, yes. But
> it does not call setVisible(false) on them, but implicitly hides them. This
> is the same how libufo behaves right now - if the parent is not visible,
> the children aren't either, not matter what m_isVisible looks like for
> them. Only if all parents are visible, m_isVisible does something.
> Same goes for setEnabled() (however this is mostly ignored by libufo atm).

Let me quote http://doc.trolltech.com/4.0/qwidget.html#enabled-prop:
"Disabling a widget implicitly disables all its children. Enabling 
respectively enables all child widgets unless they have been explicitly 
disabled."

As for the visible property:
In my last E-Mail I wrote that the intention is to get an easy way for 
querying whether a widget is mapped to screen.
The user behaviour for setVisible remains the same (i.e. if you call 
setVisible(false) on a widget, it remains invisible even if the
parent widget becomes visible).


Regards,
Johannes

Re: Visible/Enabled (Was: Re: [UFO-devel] Accelerators)

[Andreas B. <b_...@gm...>]

On Friday 10 June 2005 13:01, Johannes Schmidt wrote:
> Am Freitag 10 Juni 2005 12:04 schrieb Andreas Beckermann:
> > On Friday 10 June 2005 10:57, Johannes Schmidt wrote:
> > [...]
> >
> > > Secondly, I am pondering about a changing the behaviour of
> > > setVisible and setEnabled.
> >
> > Which change are you talking about?
>
> The change which was described below, especially when following the links.

I still don't see which change you mean
The docs that you quoted state pretty much the current behaviour of libufo, 
except for the fact that the enabled property of libufo is mostly ignored 
currently.

[...]
> > > IMHO, hiding all child widgets when calling setVisible(false) is
> > > reasonable.
> >
> > See above. If you mean by "hiding" not to show them, I agree. If you mean
> > by it calling setVisible(false) on them, I disagree.
>
> Well, as you always favor the way of QT, I thought that you'd like it.
> As described in the given APi docs, there should be some sort of
> force_invisible. But you could also introduce some new methods.

Really, I still fail to see your point, please explain further what you mean. 
Do you really want to make the behaviour of setVisible() turn into this:
void UWidget::setVisible(bool e)
{
 m_isVisible = e;
 for (all children) {
    child->setVisible(e);
 }
}
?

If so, then I think that is a _really_ bad idea. btw: Qt does _not_ do that.
In Qt setVisible(false) actually _does_ hide all children, yes. But it does 
not call setVisible(false) on them, but implicitly hides them. This is the 
same how libufo behaves right now - if the parent is not visible, the 
children aren't either, not matter what m_isVisible looks like for them.
Only if all parents are visible, m_isVisible does something.
Same goes for setEnabled() (however this is mostly ignored by libufo atm).

> Regards,
> Johannes

CU
Andi

Re: Visible/Enabled (Was: Re: [UFO-devel] Accelerators)

[Johannes S. <sch...@us...>]

Am Freitag 10 Juni 2005 12:04 schrieb Andreas Beckermann:
> On Friday 10 June 2005 10:57, Johannes Schmidt wrote:
> [...]
>
> > Secondly, I am pondering about a changing the behaviour of
> > setVisible and setEnabled.
>
> Which change are you talking about?

The change which was described below, especially when following the links.

> > A visible widget as child of an invisible widget doesn't really make
> > sense.
>
> This depends on how you mean this.
>   widget->setVisible(true);
>   widgetParent->setVisible(false);
> _does_ make sense, i.e. widgetParent does _not_ change the "visible"
> settings of its children. Because then you can do
>   widgetParent->setVisible(true);
> which makes both, the widgetParent and the widget visible again.
> So a child widget that has the "visible" property true although a parent is
> not visible _does_ make sense (same goes for enabled).
>
> Of course, if the visible property of a parent is false, all of its
> children should be hidden, too, no matter what ther visible property is set
> to. I believe this is how most (all?) widget toolkits work.
> So if you did mean this, I agree.

Yes, the main reason is to get whether a widget is mapped to screen.

> > IMHO, hiding all child widgets when calling setVisible(false) is
> > reasonable.
>
> See above. If you mean by "hiding" not to show them, I agree. If you mean
> by it calling setVisible(false) on them, I disagree.

Well, as you always favor the way of QT, I thought that you'd like it.
As described in the given APi docs, there should be some sort of 
force_invisible. But you could also introduce some new methods.


Regards,
Johannes

Visible/Enabled (Was: Re: [UFO-devel] Accelerators)

[Andreas B. <b_...@gm...>]

On Friday 10 June 2005 10:57, Johannes Schmidt wrote:
[...]
> Secondly, I am pondering about a changing the behaviour of
> setVisible and setEnabled.

Which change are you talking about?

> A visible widget as child of an invisible widget doesn't really make sense.

This depends on how you mean this.
  widget->setVisible(true);
  widgetParent->setVisible(false);
_does_ make sense, i.e. widgetParent does _not_ change the "visible" settings 
of its children. Because then you can do
  widgetParent->setVisible(true);
which makes both, the widgetParent and the widget visible again.
So a child widget that has the "visible" property true although a parent is 
not visible _does_ make sense (same goes for enabled).

Of course, if the visible property of a parent is false, all of its children 
should be hidden, too, no matter what ther visible property is set to. I 
believe this is how most (all?) widget toolkits work.
So if you did mean this, I agree.

> IMHO, hiding all child widgets when calling setVisible(false) is
> reasonable.

See above. If you mean by "hiding" not to show them, I agree. If you mean by 
it calling setVisible(false) on them, I disagree.

> Regards,
> Johannes

CU
Andi