Greetings to all. As a simple introduction may I say I thank you all for your work on Dillo. Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev. FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list. For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI). After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it. Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup. Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button. It may not seem reliable to do so many things in handle(). Any suggestions? It is functional, only you can say if it fully suits Dillo's needs though. Unfortunately, there are some problems: The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that. The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash. Thanks, Jo?o
On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote:
Greetings to all.
As a simple introduction may I say I thank you all for your work on Dillo.
Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev.
FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list.
For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI).
After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it.
Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup.
Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button.
It may not seem reliable to do so many things in handle(). Any suggestions?
We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects.
It is functional, only you can say if it fully suits Dillo's needs though.
Please post the patch here so we can look at it.
Unfortunately, there are some problems:
The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that.
Or maybe just tweaking the value. After all it's a workaround.
The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash.
A side affect of being a child of UI. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu:
On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote:
Greetings to all.
As a simple introduction may I say I thank you all for your work on Dillo.
Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev.
FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list.
For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI).
After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it.
Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup.
Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button.
It may not seem reliable to do so many things in handle(). Any suggestions?
We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects.
It is functional, only you can say if it fully suits Dillo's needs though.
Please post the patch here so we can look at it.
Unfortunately, there are some problems:
The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that.
Or maybe just tweaking the value. After all it's a workaround.
The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash.
A side affect of being a child of UI.
So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically. Jo?o
On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote:
Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu:
On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote:
Greetings to all.
As a simple introduction may I say I thank you all for your work on Dillo.
Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev.
FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list.
For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI).
After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it.
Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup.
Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button.
It may not seem reliable to do so many things in handle(). Any suggestions?
We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects.
It is functional, only you can say if it fully suits Dillo's needs though.
Please post the patch here so we can look at it.
Unfortunately, there are some problems:
The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that.
Or maybe just tweaking the value. After all it's a workaround.
The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash.
A side affect of being a child of UI.
So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically.
I'm reviewing it now. -- Cheers Jorge.-
On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote:
On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote:
Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu:
On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote:
Greetings to all.
As a simple introduction may I say I thank you all for your work on Dillo.
Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev.
FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list.
For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI).
After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it.
Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup.
Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button.
It may not seem reliable to do so many things in handle(). Any suggestions?
We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects.
It is functional, only you can say if it fully suits Dillo's needs though.
Please post the patch here so we can look at it.
Unfortunately, there are some problems:
The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that.
Or maybe just tweaking the value. After all it's a workaround.
The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash.
A side affect of being a child of UI.
So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically.
I'm reviewing it now.
Well, the good part is that it works and can be polished a bit. The problem is side effects (e.g. redraw storms while moving the mouse over the panel buttons, and who knows what else?). I tried a different approach and it almost worked OK, but after resizing the window, the redraw storms are on the whole window. Frustrating... It looks like drawing the button in the pager could work. I'll try to write some code this way. -- Cheers Jorge.-
S?b, 2009-02-07 ?s 18:33 -0300, Jorge Arellano Cid escreveu:
On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote:
On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote:
Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu:
On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote:
Greetings to all.
As a simple introduction may I say I thank you all for your work on Dillo.
Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev.
FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list.
For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI).
After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it.
Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup.
Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button.
It may not seem reliable to do so many things in handle(). Any suggestions?
We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects.
It is functional, only you can say if it fully suits Dillo's needs though.
Please post the patch here so we can look at it.
Unfortunately, there are some problems:
The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that.
Or maybe just tweaking the value. After all it's a workaround.
The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash.
A side affect of being a child of UI.
So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically.
I'm reviewing it now.
Well, the good part is that it works and can be polished a bit. The problem is side effects (e.g. redraw storms while moving the mouse over the panel buttons, and who knows what else?).
I tried a different approach and it almost worked OK, but after resizing the window, the redraw storms are on the whole window.
Frustrating...
It looks like drawing the button in the pager could work. I'll try to write some code this way.
Thanks. Redraw storms are visible when running it under valgrind. Also, parts of the code there were/are unnecessary. For instance, we could send the redraw() message only when adding a new tab and not continuously, but the redraw storms continue either way... Adding it to the pager seems the way to go there, but will you add it as a button, or a custom drawn widget? If you need any help, do say, I'll try to do my best, Jo?o
On Sat, Feb 07, 2009 at 09:57:52PM +0000, Jo?o Ricardo Louren?o wrote:
S?b, 2009-02-07 ?s 18:33 -0300, Jorge Arellano Cid escreveu:
On Fri, Feb 06, 2009 at 05:56:28PM -0300, Jorge Arellano Cid wrote:
On Mon, Feb 02, 2009 at 12:37:18AM +0000, Jo?o Ricardo Louren?o wrote:
Dom, 2009-02-01 ?s 14:51 -0300, Jorge Arellano Cid escreveu:
On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote:
Greetings to all.
As a simple introduction may I say I thank you all for your work on Dillo.
Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev.
FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list.
For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI).
After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it.
Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup.
Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button.
It may not seem reliable to do so many things in handle(). Any suggestions?
We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects.
It is functional, only you can say if it fully suits Dillo's needs though.
Please post the patch here so we can look at it.
Unfortunately, there are some problems:
The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that.
Or maybe just tweaking the value. After all it's a workaround.
The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash.
A side affect of being a child of UI.
So, as requested, here is what I have got until now. There is a particular line I think is not necessary, I commented that specifically.
I'm reviewing it now.
Well, the good part is that it works and can be polished a bit. The problem is side effects (e.g. redraw storms while moving the mouse over the panel buttons, and who knows what else?).
I tried a different approach and it almost worked OK, but after resizing the window, the redraw storms are on the whole window.
Frustrating...
It looks like drawing the button in the pager could work. I'll try to write some code this way.
Thanks. Redraw storms are visible when running it under valgrind. Also, parts of the code there were/are unnecessary. For instance, we could send the redraw() message only when adding a new tab and not continuously, but the redraw storms continue either way...
Adding it to the pager seems the way to go there, but will you add it as a button, or a custom drawn widget?
Custom drawn widget.
If you need any help, do say, I'll try to do my best,
Good! Currently I have a good start. It draws the "button" from draw_tabs() and the events can be got from CustTabGroup's handle(). I'll try to advance it a bit more and then send you the code for finishing. -- Cheers Jorge.-
A simple update. I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible). I've got a working tooltip, added to CustTabGroup. The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable. Thanks, Jo?o
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote:
A simple update.
I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible).
Good.
I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope). -- Cheers Jorge.-
Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu:
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote:
A simple update.
I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible).
Good.
I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope).
Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these. To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code: fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH); Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross... I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself. Thanks, Jo?o
On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote:
Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu:
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote:
A simple update.
I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible).
Good.
I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope).
Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these.
To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code:
fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH);
Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross...
I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself.
This works OK for me: setcolor(GRAY10); r.h(r.h()-2); drawtext("X", r, ALIGN_CENTER); (added just after fillrect()) -- Cheers Jorge.-
Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu:
On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote:
Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu:
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote:
A simple update.
I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible).
Good.
I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope).
Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these.
To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code:
fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH);
Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross...
I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself.
This works OK for me:
setcolor(GRAY10); r.h(r.h()-2); drawtext("X", r, ALIGN_CENTER);
(added just after fillrect())
OK, I've got a working patch with (as far as I can tell) one bug: Once a tooltip has popped-up in the button, if we move the cursor to the search button, the tooltip for that button will not appear, until we move out of this button and back in. A solution I found caused another bug which I considered more annoying (tooltip always visible while the mouse doesn't leave the whole tabs area). But this occurs only when moving immediatly to the search button, and not when moving to anything else (location bar works immediatly). Also, it seems that this doesn't always. Apart from that, it seems to be OK. I tried to keep indenting as close as possible, do say if I missed something. This patch includes your code, my code and my changes to your code. Thanks, Jo?o
On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote:
Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu:
On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote:
Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu:
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote:
A simple update.
I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible).
Good.
I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope).
Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these.
To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code:
fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH);
Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross...
I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself.
This works OK for me:
setcolor(GRAY10); r.h(r.h()-2); drawtext("X", r, ALIGN_CENTER);
(added just after fillrect())
OK, I've got a working patch with (as far as I can tell) one bug:
Once a tooltip has popped-up in the button, if we move the cursor to the search button, the tooltip for that button will not appear, until we move out of this button and back in. A solution I found caused another bug which I considered more annoying (tooltip always visible while the mouse doesn't leave the whole tabs area). But this occurs only when moving immediatly to the search button, and not when moving to anything else (location bar works immediatly). Also, it seems that this doesn't always.
Apart from that, it seems to be OK.
I tried to keep indenting as close as possible, do say if I missed something.
This patch includes your code, my code and my changes to your code.
Thanks,
Committed! With this minor changes: - Moved update_positions() out of the class decl. - Used event_inside() instead of our custom test. - Separated some assignements: a=b; -> a = b; - Changed the button colors, and added a highlight effect. - Made debug messages silent. It took more effort than anticipated, but now we have our shiny close-tab button. Note: the tooltip issue is still unresolved. OTOH it's so minor, we can perfectly live with it. All: please test and find it great! :-) Thanks Jo?o! BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a developer from Brazil that just joined our team! -- Cheers Jorge.-
Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu:
On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote:
Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu:
On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote:
Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu:
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote:
A simple update.
I've fixed most issues I found. For instance, we were processing the click on PUSH and not RELEASE, that was causing some problems and The issue I talked about earlier (working while not visible).
Good.
I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
The only problem is drawing into the button. Should I use an image (or multiple images, mouseover, etc...)? Should I add a cross ('X') to it? Adding a cross is easy, adding an image involves digging some more but it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope).
Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these.
To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code:
fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH);
Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross...
I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself.
This works OK for me:
setcolor(GRAY10); r.h(r.h()-2); drawtext("X", r, ALIGN_CENTER);
(added just after fillrect())
OK, I've got a working patch with (as far as I can tell) one bug:
Once a tooltip has popped-up in the button, if we move the cursor to the search button, the tooltip for that button will not appear, until we move out of this button and back in. A solution I found caused another bug which I considered more annoying (tooltip always visible while the mouse doesn't leave the whole tabs area). But this occurs only when moving immediatly to the search button, and not when moving to anything else (location bar works immediatly). Also, it seems that this doesn't always.
Apart from that, it seems to be OK.
I tried to keep indenting as close as possible, do say if I missed something.
This patch includes your code, my code and my changes to your code.
Thanks,
Committed!
With this minor changes:
- Moved update_positions() out of the class decl. - Used event_inside() instead of our custom test. - Separated some assignements: a=b; -> a = b; - Changed the button colors, and added a highlight effect. - Made debug messages silent.
It took more effort than anticipated, but now we have our shiny close-tab button.
Note: the tooltip issue is still unresolved. OTOH it's so minor, we can perfectly live with it.
All: please test and find it great! :-)
Thanks Jo?o!
BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a developer from Brazil that just joined our team!
Thanks, and I completely forgot to thank you for your help on the code! There's one small mistake there, I'm from Portugal :) Let's hope the tests work out ok! Jo?o
On Thu, Feb 12, 2009 at 02:03:03PM +0000, Jo?o Ricardo Louren?o wrote:
Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu:
On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote:
Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu:
On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote:
Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu:
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > A simple update. > > I've fixed most issues I found. For instance, we were processing the > click on PUSH and not RELEASE, that was causing some problems and The > issue I talked about earlier (working while not visible).
Good.
> I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
> The only problem is drawing into the button. Should I use an image (or > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > Adding a cross is easy, adding an image involves digging some more but > it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope).
Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these.
To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code:
fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH);
Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross...
I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself.
This works OK for me:
setcolor(GRAY10); r.h(r.h()-2); drawtext("X", r, ALIGN_CENTER);
(added just after fillrect())
OK, I've got a working patch with (as far as I can tell) one bug:
Once a tooltip has popped-up in the button, if we move the cursor to the search button, the tooltip for that button will not appear, until we move out of this button and back in. A solution I found caused another bug which I considered more annoying (tooltip always visible while the mouse doesn't leave the whole tabs area). But this occurs only when moving immediatly to the search button, and not when moving to anything else (location bar works immediatly). Also, it seems that this doesn't always.
Apart from that, it seems to be OK.
I tried to keep indenting as close as possible, do say if I missed something.
This patch includes your code, my code and my changes to your code.
Thanks,
Committed!
With this minor changes:
- Moved update_positions() out of the class decl. - Used event_inside() instead of our custom test. - Separated some assignements: a=b; -> a = b; - Changed the button colors, and added a highlight effect. - Made debug messages silent.
It took more effort than anticipated, but now we have our shiny close-tab button.
Note: the tooltip issue is still unresolved. OTOH it's so minor, we can perfectly live with it.
All: please test and find it great! :-)
Thanks Jo?o!
BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a developer from Brazil that just joined our team!
Thanks, and I completely forgot to thank you for your help on the code!
There's one small mistake there, I'm from Portugal :)
Let's hope the tests work out ok!
Hi Jo?o and welcome on board! Cheers, Johannes
On Thu, Feb 12, 2009 at 02:03:03PM +0000, Jo?o Ricardo Louren?o wrote:
Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu:
On Thu, Feb 12, 2009 at 01:31:38AM +0000, Jo?o Ricardo Louren?o wrote:
Qua, 2009-02-11 ?s 21:01 -0300, Jorge Arellano Cid escreveu:
On Wed, Feb 11, 2009 at 09:23:02PM +0000, Jo?o Ricardo Louren?o wrote:
Ter, 2009-02-10 ?s 16:55 -0300, Jorge Arellano Cid escreveu:
On Mon, Feb 09, 2009 at 09:23:38PM +0000, Jo?o Ricardo Louren?o wrote: > A simple update. > > I've fixed most issues I found. For instance, we were processing the > click on PUSH and not RELEASE, that was causing some problems and The > issue I talked about earlier (working while not visible).
Good.
> I've got a working tooltip, added to CustTabGroup.
Good 2. I feared this could be harder.
> The only problem is drawing into the button. Should I use an image (or > multiple images, mouseover, etc...)? Should I add a cross ('X') to it? > Adding a cross is easy, adding an image involves digging some more but > it is obviously doable.
Try drawing a cross with a couple of lines. After all this is a well-baheved workaround, but no more. At some point in time it will be fixed in FLTK (I hope).
Fixed a couple more issues relating to focus and events getting lost, including the tooltip not showing up after fixing some of these.
To draw the 'X', I thought of writting an 'X' there. This turned out OK: I set the color to black and, then, determine the positions of the 'X' based on fltk::measure. I thought the cross was too 'thin' so I decided to use a bold font. Now here comes the problem. For some reason, measure() uses the previously set font (although the selected is printed)). Maybe I'm missing something, here's the code:
fltk::setfont(fltk::getfont()->bold(), fltk::getsize()); int textW=0, textH=0; fltk::measure("X", textW, textH, ALIGN_CENTER); MSG("W: %d, H: %d.\n", textW, textH); fltk::drawtext("X", btn_x+textW, textH);
Any change to setfont() (bold, font itself) does not affect measure, which affects the positioning of the cross...
I tried to draw the lines, but they were simply too 'choppy' and it even looks better with the 'skinny text' itself.
This works OK for me:
setcolor(GRAY10); r.h(r.h()-2); drawtext("X", r, ALIGN_CENTER);
(added just after fillrect())
OK, I've got a working patch with (as far as I can tell) one bug:
Once a tooltip has popped-up in the button, if we move the cursor to the search button, the tooltip for that button will not appear, until we move out of this button and back in. A solution I found caused another bug which I considered more annoying (tooltip always visible while the mouse doesn't leave the whole tabs area). But this occurs only when moving immediatly to the search button, and not when moving to anything else (location bar works immediatly). Also, it seems that this doesn't always.
Apart from that, it seems to be OK.
I tried to keep indenting as close as possible, do say if I missed something.
This patch includes your code, my code and my changes to your code.
Thanks,
Committed!
With this minor changes:
- Moved update_positions() out of the class decl. - Used event_inside() instead of our custom test. - Separated some assignements: a=b; -> a = b; - Changed the button colors, and added a highlight effect. - Made debug messages silent.
It took more effort than anticipated, but now we have our shiny close-tab button.
Note: the tooltip issue is still unresolved. OTOH it's so minor, we can perfectly live with it.
All: please test and find it great! :-)
Thanks Jo?o!
BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a developer from Brazil that just joined our team!
Thanks, and I completely forgot to thank you for your help on the code!
There's one small mistake there, I'm from Portugal :)
Oh, sorry. I thought you were at unicamp. -- Cheers Jorge.-
On Thu, Feb 12, 2009 at 02:03:03PM +0000, Jo?o Ricardo Louren?o wrote:
Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu:
BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a developer from Brazil that just joined our team!
Jo?o
Hi Jo?o, welcome aboard! Dillo is a great project to work on. The code is good and the team spirit and mutual respect is good too. I'm sure you'll fit right in! Regards, Jeremy Henty
participants (5)
-
darkspirit5000＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
jorl17.8＠gmail.com -
onepoint＠starurchin.org