widget coordinate relative to parent ?

Marius Giurgi · #1 22-Feb-2005, 18:20

dear fltkers,

is there a way to set the child widget coordinate relative to its parent and not relative to the main window?

Say I create a group widget and add a bunch of children widgets to it; I want to specify the widgets coordinates relative to the group widget, thus if I need to move the group around I only have to update its coordinates relative to its parent (probably the main window) and all of its children would follow.

is there such a feature in fltk 1.1.6?

any hints appreciated. Thanks.
marius

cable_guy_67 · #2 23-Feb-2005, 06:26

Quote:

Originally Posted by Marius Giurgi

dear fltkers,

is there a way to set the child widget coordinate relative to its parent and not relative to the main window?

Say I create a group widget and add a bunch of children widgets to it; I want to specify the widgets coordinates relative to the group widget, thus if I need to move the group around I only have to update its coordinates relative to its parent (probably the main window) and all of its children would follow.

is there such a feature in fltk 1.1.6?

any hints appreciated. Thanks.
marius

marius, I will get back to you on this (I gotta get out to work

) as I am doing something similar to what you describe with the program shown in the attached image. I will post some code for this later tonight.

Mark

cable_guy_67 · #3 25-Feb-2005, 21:48

Ok Marius I think this is what you are talking about. As usual, here is the fluid project:

Code:

# data file for the Fltk User Interface Designer (fluid)
version 1.0107 
header_name {.h} 
code_name {.cxx}
decl {\#include<FL/Fl_Box.H>} {selected
} 

Function {cb_move_down(Fl_Widget* w,void*)} {open
} {
  code {if (mygroup->y() == 5) mygroup->position(5,95);

w->parent()->redraw();} {}
} 

Function {cb_move_up(Fl_Widget* w,void*)} {open
} {
  code {if (mygroup->y() == 95) mygroup->position(5,5);

w->parent()->redraw();} {}
} 

Function {cb_add_box(Fl_Widget* w,void*)} {open
} {
  code {int my_x = mygroup->x();
int my_y = mygroup->y();
int my_h = mygroup->h();
int child = mygroup->children();

if (child == 0){
  Fl_Box* mybox1 = new Fl_Box(my_x+5,my_y+5,50,my_h-10);
  mybox1->box(FL_UP_BOX);
  mygroup->add(mybox1);
}else if (child == 1){
  Fl_Box* mybox2 = new Fl_Box(my_x+65,my_y+5,50,my_h-10);
  mybox2->box(FL_UP_BOX);
  mygroup->add(mybox2);
}
w->parent()->redraw();} {}
} 

Function {} {open
} {
  Fl_Window mywin {open
    xywh {164 148 228 156} type Double visible
  } {
    Fl_Group mygroup {open
      xywh {5 5 220 55} box EMBOSSED_FRAME
    } {}
    Fl_Button {} {
      label {group dn}
      callback cb_move_down
      xywh {5 65 70 25}
    }
    Fl_Button {} {
      label {group up}
      callback cb_move_up
      xywh {80 65 70 25}
    }
    Fl_Button {} {
      label {add box}
      callback cb_add_box
      xywh {155 65 70 25}
    }
  }
  code {mywin->show();} {}
}

It only creates two FL_UP_BOXES but it should serve as an example of what you were asking about. Let me know if I missed the mark. :-)

Mark

Marius Giurgi · #4 04-Mar-2005, 13:49

well. that's a nice trick, mark. but honestly, I'd like to be able to do this in Fluid as well as programatically in a more ellegant way.

the following code generated by fluid gives the arrangement below (as expected, in picture1), however I'd like to see a result more like picture2), where the child widgets have now 40, 40 indentation relative to the main window:

CPP / C++ / C Code:

// generated by Fast Light User Interface Designer (fluid) version 1.0106
// header test.h

#ifndef test1_h
#define test1_h
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Group.H>
#include <FL/Fl_Input.H>
#endif

// generated by Fast Light User Interface Designer (fluid) version 1.0106
// code test1.cxx

#include "test1.h"

int main(int argc, char **argv) {
  Fl_Double_Window* w;
  { Fl_Double_Window* o = new Fl_Double_Window(300, 300);
    w = o;
    { Fl_Group* o = new Fl_Group(20, 20, 260, 260);
      o->box(FL_BORDER_BOX);
      new Fl_Input(20, 20, 100, 20);
      new Fl_Input(20, 50, 100, 20);
      o->end();
    }
    o->end();
  }
  w->show(argc, argv);
  return Fl::run();
}

I don't know how exactly the layout hierarchy is implemented in fltk and why the developers chose to have the absolute widget positioning (however relative to the main window) regardless of hierarchy. The relative positioning should be more intuitive and convenient to use. I assume it's not an easy task to modify the fltk internal structure to reflect this "relative" behaviour, is it?

A great advantage of this RP would be repositioning groups by just resetting their coordonates, all of its children following accordingly, having relative positioning to their parent. Also cut/paste one widget from a group to another will preserve the relative positioning to the new group.

perhaps fltk2 has this already implemented internally (i'm not sure; I didn't get to use fltk2 on my mac (os x) platform as I got some compilation errors).

Anyway, I'm sure there are tricks like this to deal with the relative positioning, however the code is not as ellegant as I'd like it to be.

cheers,
marius

cable_guy_67 · #5 04-Mar-2005, 14:18

I'm guessing I am not quite comprehending what you are after. I thought you wanted the new widgets to be relative to the group? The implementation code could use a scrub brush but the add box button will find the relative location within the group to place the new button. If perhaps you want to draw a number of (boxes for example) you could create an array of boxes that could draw relative to the group (or each other), and run through a loop. Or is it that you don't want to enter the creation code by hand and have fluid generate the code that I am using in cb_add_box?

Attach the pictures of what you are after and maybe I can clarify my code. I was trying to show that even if you move the group you will get the same result with the new box that is created because it's creation point is based on the groups current location (in my example top or bottom) and not the main window itself.

Let me know because it sounds like I not only missed the target but the barn it was attached to as well. :-?

Mark

Marius Giurgi · #6 07-Mar-2005, 12:39

What I'm after is to be able to use FLUID to create a group, put some buttons inside the group, and position them RELATIVE to the group.
Say, the group has position (x:10, y:10, w:100, h:100) while the buttons have (x:10, y:10, w:50, h:20) and (x:10, y:40, w:50, h:20), stacked on top of each other. I expect then FLUID would display them as (x:10, y:10),(x:10, y:40) relative to the group therefore (x:20, y:20),(x:20, y:50) relative to the main window.

I wonder if FLUID could be made to interpret the position values as relative to the parent instead of the main window. I don't think this shouldn't be too much of a deal. You can add an extra option to the property window in FLUID that allows the user to chose between absolute/relative positioning for a given widget. (absolute being relative to the main window, of course). Then, upon saving the .h, .cxx files FLUID would update the (absolute) values accordingly.

Check this effect out in FLUID: Create a window, create a group, and put a button inside. Everything is relative to the main window (of course). Now try to update the group positioning. As you will notice, the button inside will stay still as it has its position relative to the main window) while the group changes position: However this is an undersirable effect, as I'd like the whole group content to tag along when the group gets moved. Wouldn't you say this should be the most convenient and also intuitive way to set the widgets position?

Anyhow, regardless of whether FLUID gets this extra option built within, it would be more elegant if fltk would have relative positioning set by default.

marius

PS: I try one more time to attach the two pdf files for picture1 and picture2 I mentioned in the last post. (i'm not sure they got sent).

cable_guy_67 · #7 07-Mar-2005, 13:52

I think I finally have caught up.

I was describing something to do with fluid the compiler and you with fluid the UI builder. You are talking about what happens when using the alignment options in the screen shot attached. At least I think so.

I have to agree with you, the alignments work in ways that boggle the mind sometimes. I can't tell you how many times I suddenly ended up with a single stack of identically sized widgets that need to be re-placed. I rarely use them but have been relying on the alignment grid (there is a new attempt at this in the latest svn) instead.

Just to be clear.

new window
new group
new text input
new text input
position text input fields in group
select both widgets
choose align left
widgets are mashed against the left side

BTW, I also got fluid to crash when trying to center horizontally.

Mark

Marius Giurgi · #8 07-Mar-2005, 16:42

Well, you didn't quite get it yet.

In FLUID:
create a window (600 200 300 300)
add a group (30 30 200 200)
add to group input box (50 50 100 20)
add to group input box (50 80 100 20)

See picture1 and picture2 for the window layout and the property window for the group.

Code:

# data file for the Fltk User Interface Designer (fluid)
version 1.0106 
header_name {.h} 
code_name {.cxx}
Function {} {open
} {
  Fl_Window {} {open
    xywh {600 200 300 300} type Double visible
  } {
    Fl_Group {} {open selected
      xywh {30 30 200 200} box BORDER_BOX
    } {
      Fl_Input {} {
        xywh {50 50 100 20}
      }
      Fl_Input {} {
        xywh {50 80 100 20}
      }
    }
  }
}

If you change the values of the x and y in the GUI X: and Y: for the group widget, FLUID draws the group (box) accordingly to the new entered position (while leaving the child widgets unchanged).
FLUID does howerver move the children together with the group if you drag and drop the whole group in the main window, but it doesn't do so if you change the position by entering values into the X: and Y: fields.

Also, what I meant to say in the earlier posts is that in FLUID I should be able to set these X: and Y: values as being relative to the parent. Instead of seting the input widget position X:50 Y:50 (relative to the main window) which is dx:20 dy:20 distance from the group, I should be able to set X:20 Y:20 (relative to the group) if this is what I want (not having to calculate and add together what should be the total distance relative from the main window.

I don't think I can make it clearer than this...

marius

cable_guy_67 · #9 07-Mar-2005, 17:29

Quote:

Originally Posted by Marius Giurgi

Well, you didn't quite get it yet.

Well I was durn close. I just didn't comprehend your last little tidbit...

This here would have solved the problem from day one.

Quote:

Originally Posted by Marius Giurgi

In FLUID:
create a window (600 200 300 300)
add a group (30 30 200 200)
add to group input box (50 50 100 20)
add to group input box (50 80 100 20)

// I particularly like images as describing GUI elements can get trying...
// Could you use a format like png or jpeg though.

See picture1 and picture2 for the window layout and the property window for the group.

// Not necessary for a simple description but a nice touch

Code:

# data file for the Fltk User Interface Designer (fluid)
version 1.0106 
header_name {.h} 
code_name {.cxx}
Function {} {open
} {
  Fl_Window {} {open
    xywh {600 200 300 300} type Double visible
  } {
    Fl_Group {} {open selected
      xywh {30 30 200 200} box BORDER_BOX
    } {
      Fl_Input {} {
        xywh {50 50 100 20}
      }
      Fl_Input {} {
        xywh {50 80 100 20}
      }
    }
  }
}

Now this is the part that is so much better with a screenshot. You could have done a capture with the widget panel open and the rest showing the value changes in Fluid. However, this is quite a nice description.

Quote:

Originally Posted by Marius Giurgi

If you change the values of the x and y in the GUI X: and Y: for the group widget, FLUID draws the group (box) accordingly to the new entered position (while leaving the child widgets unchanged).
FLUID does howerver move the children together with the group if you drag and drop the whole group in the main window, but it doesn't do so if you change the position by entering values into the X: and Y: fields.

Now I really and truly understand what you want to have happen. In fact, I think this is just one of the many little things that could be fixed.

Quote:

Originally Posted by Marius Giurgi

Also, what I meant to say in the earlier posts is that in FLUID I should be able to set these X: and Y: values as being relative to the parent. Instead of seting the input widget position X:50 Y:50 (relative to the main window) which is dx:20 dy:20 distance from the group, I should be able to set X:20 Y:20 (relative to the group) if this is what I want (not having to calculate and add together what should be the total distance relative from the main window.

I don't think I can make it clearer than this...

marius

I bet you could but this is pleanty thanks.

I think that there are many things like this that need corrective action. For example, if you have 3 buttons in a line and you should be able to set them centered as a group in a group. You can work around some of these things by enclosing widget groups in their own groups and then placing them in the main group. Sadly though, this functionality of which you speak does not exist yet.

Yet there is hope. If you have Fluid you have fluid.cxx. I have been working on adding the ability to add a file of GPL comments to the beginning of the created .cxx, .h and .fl files. The code is not terribly complex all things considered. Climb in and have some fun with it.

Well, that was a pretty long winded way to say I can't help solve your problem. Hope you enjoyed the conversation anyhow.

Mark

Marius Giurgi · #10 08-Mar-2005, 11:38

I did enjoy the conversation, thank you

and also I appreciate your intention of helping me solve this issue. Also I hoped that us talking on this topic will hint other developers to consider it for the future fltk versions.

If time permits I will take a look at the fluid.cxx and try to improve it (even though I don't consider myself mastering c++ yet). However, as I said, improving fluid itself in this respect will still not solve the programatical aspect of the relative positioning (as this should be rather dealt with by the fltk itself), fluid would only mask the positioning issue by doing the absolute calculation for you. When I expressed my desire to have this implemented within fltk itself I was hoping some fltk developer would preceive my frustration, implement the relative positioning and issue a new fltk 1.1.x version the next day hehe

Kidding of course, but the hope nevertheless it's there.

cheers,
marius

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Rate This Thread
Rate This Thread:

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
How to refresh a widget immediately	dsmith	FLTK Forum	8	11-Dec-2004 01:54