Popup menus and exec buttons

Hello,


after Eric's suggestions to use popup menus instead of a row
of buttons 
I played with the popup widget. I prefer to use a popup menu
which is 
available via exec button click but I am not able to do such
a thing. 
My problem is, that there is no exec button function or slot
which 
tells the popup menu its correct position. There are only
slots 
available which can access the popup menu as context menu.
And these 
slots are only available to the form itself and the group
widgets. 
The function popupwidgetname.popup(int x, int y) works well,
but I have 
no idea, how the get the current button position or the
current cursor 
position to enable the menu to its right place. I hoped the
current 
cursor position is available via a kwin dcop call, but I
found 
nothing relevant.

The attached image descripes what I like to do. 


cu alex



_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 06 March 2008 1:41:48 am Alexander Fischer
wrote:
> Hello,
>
>
> after Eric's suggestions to use popup menus instead of
a row of buttons
> I played with the popup widget. I prefer to use a popup
menu which is
> available via exec button click but I am not able to do
such a thing.
> My problem is, that there is no exec button function or
slot which
> tells the popup menu its correct position. There are
only slots
> available which can access the popup menu as context
menu. And these
> slots are only available to the form itself and the
group widgets.
> The function popupwidgetname.popup(int x, int y) works
well, but I have
> no idea, how the get the current button position or the
current cursor
> position to enable the menu to its right place. I hoped
the current
> cursor position is available via a kwin dcop call, but
I found
> nothing relevant.
>
> The attached image descripes what I like to do.
>
>
> cu alex

Please stop sending images! I barely approved this and
rejected another. Lets 
be kind to subscribers who many not have broadband.

The answer to your question...

Early on as there was no createWidget call there was little
need for widget 
position information. It is useful now. You can also set
position and size 
with slots as that was not filtered like the signal/slot
dialog. 
Unfortunately the only way to get this information is with
DCOP in the qt 
interface. I used this earlier today to position a created
DatePicker which 
may or may not be embedded in a KPart.

  x = exec("dcop "+dcopid+"
"qt/Form4/ExecFromDate" property x")
  if x == "object not accessible" then
    x = exec("dcop "+dcopid+" 
"qt/KHphone/qt_central_widget/GroupBox4/KPartImport1/u
nnamed2(QWidget, 
0x703b90)/Form4/ExecFromDate" property x")
    y = exec("dcop "+dcopid+" 
"qt/KHphone/qt_central_widget/GroupBox4/KPartImport1/u
nnamed2(QWidget, 
0x703b90)/Form4/ExecFromDate" property y")
  else
    y = exec("dcop "+dcopid+"
"qt/Form4/ExecFromDate" property y")
  endif
  y = str_toint(y)+30
  fromDate.move(x, y)
  fromDate.setVisible(true)

I trust you know how to find qt widgets with theDCOP call
using "objects | 
grep mywidget". As I said before I use an exec() call
instead of a dcop() 
call as I haven't been able to get the syntax to work right
with the qt 
interface. 

Just a note, I consider the use of buttons for context menus
tacky and would 
use the right click, even putting a tooltip on the widget
indicating that. 
One of the things context menus do is help you to eliminate
the clutter of 
buttons everywhere and allow much more in depth context
related actions. 
However if you want to do this I'm sure it can be done. Any
calls to the menu 
put it in random places on the screen, but one slot may
still accept x y info 
or you could position it manually. If it uses screen
coordinates though you 
have a fun job ahead.  A
tooltop that says "right click for menu" is far 
easier and more reliable. 

-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 06 March 2008 4:41:48 am Alexander Fischer
wrote:
> Hello,
>
>
> after Eric's suggestions to use popup menus instead of
a row of buttons
> I played with the popup widget. I prefer to use a popup
menu which is
> available via exec button click but I am not able to do
such a thing.
> My problem is, that there is no exec button function or
slot which
> tells the popup menu its correct position. There are
only slots
> available which can access the popup menu as context
menu. And these
> slots are only available to the form itself and the
group widgets.
> The function popupwidgetname.popup(int x, int y) works
well, but I have
> no idea, how the get the current button position or the
current cursor
> position to enable the menu to its right place. I hoped
the current
> cursor position is available via a kwin dcop call, but
I found
> nothing relevant.
>
> The attached image descripes what I like to do.
>
>
> cu alex

Don't necessarily give up on the use of the popup widget -
that's still the 
best way to go, but you can approximate what you want very
easily with a 
combobox, an array, and a simple script.

Create a comboBox with a list of items representing the
commands you want to 
execute.  That also serves as your 'exec button'.  Make the
first item in the 
list your label (In the image, you used >> ) and that
will be a 'dummy'.  
Everything else in the list should represent a command you
want to execute.

Initialize an array (easiest during the form1(editor dialog)
initialization) 
with something like the following
array_fromString("_exec_choices",
"0tdummyn1tprogramlineAn2tprogramlineB")
replacing programlineA & B with whatever you want to
execute.  The keys 0, 1, 
2, etc will match the item number in the comboBox.

Create a script that tests if ComboBox.currentItem is the
dummy.  If not, run 
something like
exec(_exec_choices[execComboBox.currentItem]), then set the

ComboBox back to 0 after it executes your command.

finally, set a connector from the ComboBox for a change in
the current item, 
to execute the script. 

hth,
-- 
Dan
Finding a solution to a problem doesn't solve the
problem...
Implementing the solution, solves the problem
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 06 March 2008, Alexander Fischer wrote:
> Hello,
>
>
> after Eric's suggestions to use popup menus instead of
a row of
> buttons I played with the popup widget. I prefer to use
a popup menu
> which is available via exec button click but I am not
able to do such
> a thing. 

Well, the popup menu is there for a context menu. What you'd
like to do 
is a different widget, a button with multiple selections.
That can be 
done with a different widget, which is not available inside
Kommander 
(you could create a plugin providing such widget if you
want).

> My problem is, that there is no exec button function or
slot
> which tells the popup menu its correct position. 

Right, you need to find the mouse cursor position, at least.
There is no 
such function in Kommander. But you might get it from an
external script 
or try the DCOP example Eric gave to you.

> cursor position to enable the menu to its right place.
I hoped the
> current cursor position is available via a kwin dcop
call, but I
> found nothing relevant.

Beware that you should not rely on kwin or anything else
running, if you 
want portable code. Of course, relying on external apps is
no problem if 
you check their existence on startup, but relying on the
window manager 
would be wrong IMO.


Andras
-- 
 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 06 March 2008 12:12:16 pm Eric Laffoon wrote:
> Unfortunately the only way to get this information is
with DCOP in the qt
> interface. I used this earlier today to position a
created DatePicker which
> may or may not be embedded in a KPart.
>
>   x = exec("dcop "+dcopid+"
"qt/Form4/ExecFromDate" property x")
>   if x == "object not accessible" then
>     x = exec("dcop "+dcopid+"
>
"qt/KHphone/qt_central_widget/GroupBox4/KPartImport1/u
nnamed2(QWidget,
> 0x703b90)/Form4/ExecFromDate" property x")
>     y = exec("dcop "+dcopid+"
>
"qt/KHphone/qt_central_widget/GroupBox4/KPartImport1/u
nnamed2(QWidget,
> 0x703b90)/Form4/ExecFromDate" property y")
>   else
>     y = exec("dcop "+dcopid+"
"qt/Form4/ExecFromDate" property y")
>   endif
>   y = str_toint(y)+30
>   fromDate.move(x, y)
>   fromDate.setVisible(true)

I seem to use "unfortunately" a lot here. Here is
another. Note the unnamed 
QWidget in the address. As I feared, it changed. Here is a
working button 
text. The button name is ExecFromDate. There is a text box
(fromDate) and a 
script (ScriptObjectFD).
//"ScriptObjectFD", 
fdate.setText(fromDate.text)
fromDate.setVisible(false)
_fdvisible = false

//ExecFromDate
if !widgetExists("fromDate") then
  createWidget("fromDate", "DatePicker",
"Form5")
  connect("fromDate",
"dateSelected(QDate)", "ScriptObjectFD",
"execute()")
endif
if _fdvisible == false then
  x = exec("dcop "+dcopid+"
"qt/Form5/ExecFromDate" property x")
  if !str_isNumber(x) then //sure fire test
    path = exec("dcop "+dcopid+" qt objects |
grep ExecFromDate")
    x = exec("dcop "+dcopid+"
""+path+"" property x")
    y = exec("dcop "+dcopid+"
""+path+"" property y")
  else
    y = exec("dcop "+dcopid+"
"qt/Form5/ExecFromDate" property y")
  endif
  y = str_toint(y)+30
  fromDate.move(x, y)
  fromDate.setVisible(true)
  _fdvisible = true
else
  fromDate.setVisible(false)
  _fdvisible = false
endif

If you want an explanation...
_fdvisible is the global we keep track of the visibility of
the DatePicker 
named "fromDate" with. First we check to see if it
exists. There is no point 
seeing how many bugs we can introduce creating it over and
over. If not, we 
also connect it to the script. If the widget is visible we
make it invisible, 
but if it is invisible we are going to need to know where to
put it.

The first call to x assumes it is directly on the form named
Form5. If it were 
in a groupbox or tab widget then this address would not
work, but even so the 
next section will find it regardless as there can only be
one widget with any 
given name on a dialog. If the first call worked x will be a
number in pixels 
from the left of the dialog. If not we will now look for it,
which would be 
the case if it were in a KPart. The path varaible will get
the complete qt 
object address of the widget. Now we will get x and y for
sure.

Once we have these we set y to plus 30 pixels so it will
drop below the button 
calling it. Note the use of str_toint(y) which keeps a y of
100 from becoming 
10030 instead of 130. (Not using this could place the widget
off the dialog 
and make it look like it didn't work when you just
concatonated text instead 
of adding integers.) In my case the button is on the left
and has a 22x22 
icon. The LineEdit is on the right. Since we got the upper
left corner of the 
button for x the DatePicker will appear to drop down off of
the button when 
it becomes visible. That is the slot call to move(x, y).

Note we make it visible after positioning it so as to avoid
flicker. This 
could be done with a listbox for extra wide results, or a
table for columns. 
However it will clip if it goes over the edge. Of course you
could create a 
dialog and position it. I haven't tried removing the
titlebar yet. If anyone 
does this please post it.

Enjoy!
-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander