Hi there, Please help me with this one. Attached goes a small program that shows what may be a bug in fltk-1.3: * resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!? My doubts are: Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented? I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean. What do you think? PS: compile with: fltk-config --compile rsz.cc -- Cheers Jorge.-
Hi Jorge, I didn't really dive into this, but the following discussion seems to be related: http://www.mail-archive.com/fltk@easysw.com/msg02113.html Cheers, Johannes On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote:
Hi there,
Please help me with this one.
Attached goes a small program that shows what may be a bug in fltk-1.3:
* resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!?
My doubts are:
Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented?
I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean.
What do you think?
PS: compile with: fltk-config --compile rsz.cc
-- Cheers Jorge.-
#include <stdio.h> #include <stdlib.h>
#include <FL/Fl.H> #include <FL/Fl_Window.H> #include <FL/Fl_Widget.H> #include <FL/Fl_Group.H> #include <FL/Fl_Button.H> #include <FL/Fl_Pack.H>
Fl_Pack *p1; Fl_Group *g1, *g2, *g3;
////////////////////////////////////////////////////////////////
static void b1_cb(Fl_Widget *w, void *data) { Fl_Group *g2 = (Fl_Group *)data;
if (g2->visible()) { g2->hide(); g3->size(g3->w(),g3->h()+g2->h()); g2->window()->redraw(); } }
static void b2_cb(Fl_Widget *w, void *data) { Fl_Group *g2 = (Fl_Group *)data;
if (!g2->visible()) { g3->size(g3->w(),g3->h()-g2->h()); g2->show(); g2->window()->redraw(); } }
int main(int argc, char **argv) { Fl_Button *b1, *b2, *b3;
Fl_Window *window = new Fl_Window(400, 400, "Fl_Pack test"); window->begin(); p1 = new Fl_Pack(0,0,400,400); p1->type(Fl_Pack::VERTICAL); p1->begin(); // a Pack with a resizable widget inside g1 = new Fl_Group(0,0,0,30, "Group 1"); g1->align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE); g1->box(FL_UP_BOX); g1->color(FL_CYAN); g1->end();
g2 = new Fl_Group(0,0,0,30, "Group 2"); g2->align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE); g2->box(FL_UP_BOX); g2->color(FL_RED); g2->end();
g3 = new Fl_Group(0,0,0,280, "Group 3 R e s i z a b l e"); g3->align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE); g3->box(FL_UP_BOX); g3->color(FL_GREEN); g3->end(); b1 = new Fl_Button(0,340,50,30); b1->label("Hide G2"); b1->callback(b1_cb, g2); b2 = new Fl_Button(0,370,50,30); b2->label("Show G2"); b2->callback(b2_cb, g2); p1->end(); p1->resizable(g3); window->end();
window->resizable(window); window->show(); return Fl::run();
return 0; }
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
Hi Jorge, On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote:
Hi there,
Please help me with this one.
Attached goes a small program that shows what may be a bug in fltk-1.3:
* resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!?
My doubts are:
Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented?
I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean.
What do you think?
Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created. I suggest we don't use Fl_Pack and make our own solution. I will try to get something running. Cheers, Johannes
On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote:
Hi there,
Please help me with this one.
Attached goes a small program that shows what may be a bug in fltk-1.3:
* resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!?
My doubts are:
Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented?
I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean.
What do you think?
Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created.
I suggest we don't use Fl_Pack and make our own solution. I will try to get something running.
Please check the attached modified version of your test program. Does the CustPack class solve your problem? Cheers, Johannes
On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote:
On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote:
Hi there,
Please help me with this one.
Attached goes a small program that shows what may be a bug in fltk-1.3:
* resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!?
My doubts are:
Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented?
I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean.
What do you think?
Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created.
I suggest we don't use Fl_Pack and make our own solution. I will try to get something running.
Please check the attached modified version of your test program. Does the CustPack class solve your problem?
Thanks for the code, I'll check it. I also had to resort to a superclass for horizontal groups in the UI (see rearrange()) BTW, I wrote to Michael Sweet (got no answer so far), because I can't believe something so simple as hidding a widget can be as convoluted as it is now. -- Cheers Jorge.-
On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote:
On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote:
Hi there,
Please help me with this one.
Attached goes a small program that shows what may be a bug in fltk-1.3:
* resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!?
My doubts are:
Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented?
I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean.
What do you think?
Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created.
I suggest we don't use Fl_Pack and make our own solution. I will try to get something running.
Please check the attached modified version of your test program. Does the CustPack class solve your problem?
It's quite similar to current CustGroup, the good news is that resizing the hidden widgets to 0,0 avoids Fl_Group resizing them later! Now we don't have to remove/re-add them to the group. This may be our workaround (not as hackish as current code). I was thinking of fullscreen mode, and having to remove groups of widgets to avoid the hidden resize. I'll forward the email to Matthias Melcher, because I still can't believe the current resize behaviour is intended. -- Cheers Jorge.-
On Tue, Mar 22, 2011 at 04:29:05PM -0300, Jorge Arellano Cid wrote:
On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote:
On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote:
Hi Jorge,
On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote:
Hi there,
Please help me with this one.
Attached goes a small program that shows what may be a bug in fltk-1.3:
* resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!?
My doubts are:
Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented?
I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean.
What do you think?
Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created.
I suggest we don't use Fl_Pack and make our own solution. I will try to get something running.
Please check the attached modified version of your test program. Does the CustPack class solve your problem?
It's quite similar to current CustGroup, the good news is that resizing the hidden widgets to 0,0 avoids Fl_Group resizing them later! Now we don't have to remove/re-add them to the group.
This may be our workaround (not as hackish as current code). I was thinking of fullscreen mode, and having to remove groups of widgets to avoid the hidden resize.
I'll forward the email to Matthias Melcher, because I still can't believe the current resize behaviour is intended.
Yesterday I wrote Matthias Melcher, and he told me he was going to review the issue. In the meanwhile (which can be long) I just committed a simple patch to make fullscreen work again (it uses the size(0,0) trick) AFAIS, by now dillo_port1.3 branch is as usable (or better) as fltk2-based dillo. :-) -- Cheers Jorge.-
On Wed, Mar 23, 2011 at 03:25:24PM +0000, Jeremy Henty wrote:
Jorge Arellano Cid wrote:
AFAIS, by now dillo_port1.3 branch is as usable (or better) as fltk2-based dillo. :-)
Is there going to be another release of dillo-fltk2?
Most probably yes. AFAIS there's not much of a point in making it _right now_, as FLTK2 will not be released. I believe a good time to make a dillo-fltk2 release is just after fltk-1.3 is released. That way we can inform users we'll be developing the fltk-1.3-based branch, and point them to the new repo. The big news is that once FLTK-1.3 is released, it will make its way into distros, making dillo accessible via package manager at some not-too-distant point in time. -- Cheers Jorge.-
participants (3)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org