[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    [Solved,
From:       "Friedrich W. H. Kossebau" <kossebau () kde ! org>
Date:       2009-06-18 23:10:31
Message-ID: 200906190110.32411.kossebau () kde ! org
[Download RAW message or body]

Hi,

see http://websvn.kde.org/?view=rev&revision=983734, esp. the classes 
Statusbar and StatusBarLayout for a quick'n'dirty shot at the problem which 
seems to work for at least non-stretching/expanding embedded items :)

So Okteta can now be resized to a very minimum, without being limited by all 
the stuff in the status bar. You won't be able to access the hidden stuff, 
but it is redundant anyway.

Vendredi, le 12 juin 2009, à 22:36, Friedrich W. H. Kossebau a écrit:
> Vendredi, le 12 juin 2009, à 21:35, Thomas Lübking a écrit:
> > Am Friday 12 June 2009 schrieb Friedrich W. H. Kossebau:
> > > So I am not sure how much of a hack this is going to be.
> >
> > Pretty much, i fear. Just tested just for fun and the main problem seems
> > to access the widgets inside the StatusBar (they're organized in a layout
> > in a layout in a layout... (itemAt(0)->itemAt(1)->itemAt(x) - if you
> > don#t do anything on temporary messages) so you'll have to reimplement
> > the add/inser/remove functions and keep your own widget list if you want
> > to do that.
> > the resizeEvent itself is however simple - just refer to
> > minimumSize().width() of the QStatusbar::layout() instead of
> > QWidget::minimumWidth()
>
> How? Would you mind to send me your test code? :)

Thanks for the code. It just had the flaw that each resize (and redraw) always 
put one stop to the current mininum size, so larger resizes always stopped at 
the current last widget, only then removed it, and had the resize proceed to 
the next widget. But it gave me the start for some ideas. :)

> > > I still wonder that I am the first one with this need. And usually I am
> > > not and there is already a Qt solution. Something like a smart layout
> > > class
> >
> > What about a QToolBar inside the statusbar then?  (or replacing it,
> > wrapping some slots to a QLabel inside the
> > You can add about any "action" (widgetaction...) and as a big fat bonus
> > you'll get a "drop down" extension out of the box?!
> >
> > > which does the calculation and manages the included widgets
> > > accordingly. I mean the toolbar can do this, too.
> >
> > ...first read the entire mail, then answer. first read the entire mail,
> > then... D'OHH
> >
> > However, looking at okteta, there's a left-side stausbar (position,
> > selection) and some toolbuttons on the right side (file mode),
>
> (There are even more items of all kinds, just not activated any longer
> currently, as it would force a mainwindow too large all the time, that is
> what I want to fix here :)
>
> > so what
> > would prevent you from just adding a toolbar to the statusbar and placing
> > the buttons there instead of "abusing" the statusbar as toolbar?
>
> Abusing, well, in my eyes it sucks to not be able to change the values
> where you see them. And one feature of KStaturBar is to make the (text)
> entries clickable, so others already started in this direction. And I have
> seen mentioning of the statusbar in XMLGUI.
>
> The toolbar is an interesting idea for a quick'n'dirty workaround, thanks.
>
> I meanwhile started to do my own QLayout subclass (lending from
> QToolBarLayout), which seems like the proper Qt solution.
>
> Hm. Okay, trying QToolBar first, might be quicker. Then the
> KStatusBarLayout might be a solution for KStatusBar one day... no...
> QToolBar first.

QToolBar lost on the next, here not documented thought iteration ;)

Thanks
Friedrich
-- 
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]