Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 18 Dec 2017, 08:57
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
GtkDialog - tips
Post new topic   Reply to topic View previous topic :: View next topic
Page 80 of 82 [1226 Posts]   Goto page: Previous 1, 2, 3, ..., 78, 79, 80, 81, 82 Next
Author Message
Geoffrey


Joined: 30 May 2010
Posts: 2313
Location: Queensland

PostPosted: Wed 16 Aug 2017, 02:52    Post subject:  

Moose On The Loose wrote:
MochiMoppel wrote:
@smokey01. Not really a Gtkdialog issue. See here.
The long # string is there to prevent the file to be mistakenly recognized as a svg image.


Perhaps this is a better way:

Code:

THING="SVG"
echo "<$THING" '.... more stuff ....


It is based on something commonly done for making html tags in javascript



Yea that worked
Code:
#!/bin/sh

SVG=svg

svg_buttons () {
echo '<'$SVG' width="100%" height="100%" viewBox="0 0 60 20">
    <defs>
    <linearGradient id="button_surface" gradientUnits="objectBoundingBox"
      x1="1" x2="1" y1="0" y2="1">
      <stop stop-color="#D26F6F" offset="0"/>
      <stop stop-color="#FF0000" offset="0.67"/>
    </linearGradient>

    <linearGradient id="virtual_light" gradientUnits="objectBoundingBox"
      x1="0" x2="0" y1="0" y2="1">
      <stop stop-color="#EEEEEE" offset="0" stop-opacity="0.8"/>
      <stop stop-color="#EEEEEE" offset="0.4" stop-opacity="0"/>
    </linearGradient>
  </defs>

  <!-- button content -->
  <rect x="0" y="0" width="60" height="20" fill="url(#button_surface)" stroke="#570B0B"/>

  <text x="17" y="15" fill="white"
    font-family="Tahoma" font-size="14" font-weight="bold">
    Kill
  </text>

  <!-- vitual lighting effect -->
  <rect x="2" y="2" width="56" height="16" fill="url(#virtual_light)" stroke="#FFFFFF" stroke-opacity="0.4"/>
</svg>
'>/tmp/killk.svg
}
export -f svg_buttons

svg_buttons

defaultimageviewer /tmp/killk.svg

_________________
Carolina: Recent Repository Additions

Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1399
Location: Japan

PostPosted: Wed 16 Aug 2017, 06:04    Post subject:  

Geoffrey wrote:
Yea that worked
Sure it works, but there is no need for a variable:
Code:
echo '<''svg width="100%" ....
Back to top
View user's profile Send private message 
smokey01


Joined: 30 Dec 2006
Posts: 2659
Location: South Australia

PostPosted: Wed 16 Aug 2017, 06:40    Post subject:  

Cool, works a treat. Thanks to all who answered.
_________________
Software <-> Distros <-> Tips <-> Newsletters
Back to top
View user's profile Send private message Visit poster's website 
zigbert


Joined: 29 Mar 2006
Posts: 6525
Location: Valåmoen, Norway

PostPosted: Wed 16 Aug 2017, 18:59    Post subject:  

The main post is updated with this new knowledge about manual sorting of a list. The solution is provided by MochiMoppel.

My question is if my explanation is understandable? (and did I get it right, Mochi?)

I have uploaded a development release of pMusic using this new approach to move tracks in the playqueue. The code is seen in /usr/local/pmusic/gui_playlist

_______________________________________________________


Drag'n drop
Gtkdialog has limited support for drag'n drop. This is what we've learnt by now:
>> Drag from file browser (rox) to <entry> widget.
Code:
export test="
<entry accept=\"directory\" width-request=\"300\">
 <default>Drag a directory from Rox</default>
</entry>"
gtkdialog -p test



>> Move items in list by drag'n drop.
Using the reorderable option in the <tree> has some strange behavior. For example will items get swallowed when moving them onto another item. The workaround restores the list if the user moves item onto, instead of in between 2 other items... This code by MochiMoppel is a result of 2 cracked nuts:
- When moving an item in the list the $PTR_Y variable returns 0. This gives us the info that the user is moving rather than clicking.
- When a signal is defined in the <tree>, user defined actions are processed before the built-in actions. The trick is to activate the invisible button, and run the user-defined actions there - after the builtin save-command

Code:
#!/bin/bash
#Code below line 15 (break:) is activated when user move item in list

ls -1 /usr/share/backgrounds > /tmp/test
do_something () { Xdialog -info  "Do something with\n$TREE" x 2000 ;} ; export -f do_something
echo '
<vbox>
   <tree headers-clickable="false" reorderable="true">
      <label>Backgrounds</label>
      <input>cat /tmp/test</input>
      <output file>/tmp/test</output>
      <variable>TREE</variable>
      <height>300</height><width>200</width>
      <action>do_something &</action>
      <action signal="button-release-event" condition="command_is_true( echo $PTR_Y )">break:</action>
      <action signal="button-release-event">save:TREE</action>
      <action signal="button-release-event">activate:BTN_SAVE</action>
   </tree>
   <button visible="false">
      <variable>BTN_SAVE</variable>
      <action>cp /tmp/test /tmp/testbackup</action>
      <action>save:TREE</action>
      <action condition="command_is_true([[ $(wc </tmp/test) != $(wc </tmp/testbackup) ]] && sed \"s/^|*//\" /tmp/testbackup > /tmp/test && echo true )">refresh:TREE</action>
   </button>
</vbox>' | gtkdialog -s


For the record, we keep the old solution for this task...
Code:
#!/bin/sh

move (){
   PRESS_EVENT=$(cat /tmp/PRESS_EVENT)
   [[ $PRESS_EVENT && $TREE ]] || exit #exit if at least one of the 2 values is empty
   [[ $PRESS_EVENT == $TREE ]] && exit #exit if both are equal (=single or double click)
   sed -i "/$PRESS_EVENT/d; /$TREE/ i\\$PRESS_EVENT" /tmp/list #remove PRESS_EVENT, then insert item PRESS_EVENT before item $TREE
}

export -f move
ls -1 /usr/share/backgrounds > /tmp/list

export test="
<tree rules_hint=\"true\" hover-selection=\"true\" tooltip-text=\"Drag'n drop items to move them in list\">
 <label>Backgrounds</label>
 <input>cat /tmp/list</input>
 <variable>TREE</variable>
 <height>300</height><width>200</width>
 <action signal=\"button-press-event\">echo \$TREE > /tmp/PRESS_EVENT</action>
 <action signal=\"button-release-event\">move</action>
 <action signal=\"button-release-event\">refresh:TREE</action>
</tree>"
gtkdialog -p test

_________________
Stardust resources
Back to top
View user's profile Send private message Visit poster's website 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1399
Location: Japan

PostPosted: Sat 19 Aug 2017, 09:44    Post subject:  

zigbert wrote:
My question is if my explanation is understandable?
No answers - is that good or bad? Laughing

Quote:
did I get it right, Mochi?
Well....almost Wink

Before I explain allow me one comment on the above "Drag from file browser" example: The accept=\"directory\" attribute makes no sense without a corresponding (and deprecated) "fileselect" function. Might give the false impression that the example accepts only directories.

Quote:
- When moving an item in the list the $PTR_Y variable returns 0. This gives us the info that the user is moving rather than clicking.

Return value of 0 is possible with clicking, so a value of 0 is not 100% proof for moving. For the code I use the opposite. I check if return value is not 0, and that MUST be a click, can't be a move.

I propose:
"A return value >0 gives us the info that the user is clicking rather than moving."

Quote:
- When a signal is defined in the <tree>, user defined actions are processed before the built-in actions. The trick is to activate the invisible button, and run the user-defined actions there - after the builtin save-command

We probably mean the same thing but I wouldn't understand your explanation if I wouldn't have written the code myself. Very difficult to put this complex process into 2 sentences and I recommend that you add a link to the drag&drop&go thread, just to keep Tips & Tricks short and provide a place for follow-up questions/explanations.

Terminology is also a problem. AFAIK there are no established terms.
I'll give it a try and list the actions in the order of execution:
- custom actions (actions within <action> tags for non-default signals)
- default actions (actions within <action> tags for the default signal - if defined)
- built-in actions (actions performed automatically, no <action> tags required)

In this sense the reordering when releasing the mouse button is a built-in action, but the save action is not.

The whole process is interesting and full of surprises. Fascinating that the trick works when activating an invisible button but not when activating an invisible menuitem (which I prefer and use a lot in MMview). If it's not too boring I can post a mock-up of the tree reordering code which will show step-by-step what gtkdialog does. You would see immediately why the first save command saves the old item order and not the new one.

Back to the description. My draft proposal:
"- Normally all <action>s defined for a widget are processed before built-in actions (actions that don't require an <action> tag). The trick is to process a user defined <action> after a built-in action. An invisible button allows the code to run a user defined save action after a built-in reorder action."
Back to top
View user's profile Send private message 
zigbert


Joined: 29 Mar 2006
Posts: 6525
Location: Valåmoen, Norway

PostPosted: Tue 22 Aug 2017, 15:11    Post subject:  

MochiMoppel wrote:
Before I explain allow me one comment on the above "Drag from file browser" example: The accept=\"directory\" attribute makes no sense without a corresponding (and deprecated) "fileselect" function. Might give the false impression that the example accepts only directories.
Of course - fixed Wink
_________________
Stardust resources
Back to top
View user's profile Send private message Visit poster's website 
zigbert


Joined: 29 Mar 2006
Posts: 6525
Location: Valåmoen, Norway

PostPosted: Tue 22 Aug 2017, 15:28    Post subject:  

MochiMoppel wrote:
I propose:
"A return value >0 gives us the info that the user is clicking rather than moving."
MochiMoppel wrote:
Back to the description. My draft proposal:
"- Normally all <action>s defined for a widget are processed before built-in actions (actions that don't require an <action> tag). The trick is to process a user defined <action> after a built-in action. An invisible button allows the code to run a user defined save action after a built-in reorder action."
Thank you, I have updated... Very Happy
But, I removed (actions that don't require an <action> tag), as it didn't gave me any meaning without the deeper explanation. I think built-in actions is understandable just as is...

A added a link to the drag an drop thread

Sigmund

_________________
Stardust resources
Back to top
View user's profile Send private message Visit poster's website 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8348
Location: Perth, Western Australia

PostPosted: Wed 23 Aug 2017, 08:45    Post subject:  

Guys,
Someone gave me the answer to this question sometime ago, but I can't recall the answer, nor who gave it Sad

When a horizontal row of buttons is created, they default to pack together on the right side.

But, if you want the left-most one or more buttons to move over to the extreme left of the window (leaving the others on the right side), how to do that?

My old way was to pack spaces between, but there is a more exact method.

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1399
Location: Japan

PostPosted: Wed 23 Aug 2017, 09:22    Post subject:  

BarryK wrote:
My old way was to pack spaces between, but there is a more exact method.
What do you mean by "more exact". Zigbert describes a solution on page 1 of this thread. Not exact enough ? Laughing

zigbert wrote:
Dynamic: (align one button to the left, another to the right)
Code:
<hbox space-expand="false" space-fill="false">
   <button yes></button>
   <hbox space-expand="true" space-fill="true"><text><label>""</label></text></hbox>
   <button no></button>
 </hbox>


Personally I find zigbert's example a bit "over-engineered". This should give a similar result, with evenly proportioned buttons when resizing the window:
Code:
<hbox space-expand="true" space-fill="true">
<button yes></button>
<text  label=""></text>
<button no></button>
</hbox>
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8348
Location: Perth, Western Australia

PostPosted: Wed 23 Aug 2017, 19:04    Post subject:  

MochiMoppel,
Thanks for that!

Trying exactly as per zigbert's example, there is a problem. I placed the text label after the first three items, but those first three do not pack together at the left side.

They are spread out, as shown in attached photo:
sns.png
 Description   
 Filesize   14.76 KB
 Viewed   177 Time(s)

sns.png


_________________
http://barryk.org/news/

Last edited by BarryK on Wed 23 Aug 2017, 19:53; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
don570


Joined: 10 Mar 2010
Posts: 4812
Location: Ontario

PostPosted: Wed 23 Aug 2017, 19:16    Post subject:  

Let's give credit to Thunor who was first Laughing

Code:
A text widget that has space-expand and space-fill set to true can be used as a spacer to push neighbouring widgets in certain directions.

Here the spacer text is "[]" so you can see it -- drag the window out and watch the button.
   
#!/bin/sh

GTKDIALOG=gtkdialog

Spacer="[]"

MAIN_DIALOG='
<window title="Spacer Test" window-position="1">
   <vbox>
      <hbox>
         <button space-expand="false" space-fill="false">
            <label>This button will stay put</label>
            <input file stock="gtk-about"></input>
         </button>
         <text space-expand="true" space-fill="true">
            <label>"'$Spacer'"</label>
         </text>
      </hbox>
   </vbox>
</window>
'
export MAIN_DIALOG

case $1 in
   -d | --dump) echo "$MAIN_DIALOG" ;;
   *) $GTKDIALOG --program=MAIN_DIALOG ;;
esac   

Regards,
Thunor
__________________________________________
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 8348
Location: Perth, Western Australia

PostPosted: Wed 23 Aug 2017, 20:09    Post subject:  

Fixed it. Zigbert's example needed a change:

Code:
<hbox>
   <button  space-expand="false" space-fill="false">...</button>
   <button  space-expand="false" space-fill="false">...</button>
   <hbox space-expand="true" space-fill="true"><text><label>""</label></text></hbox>
   <button no></button>
 </hbox>


The first two buttons pack to the left.

But then, why have that nested hbox? No need:

Code:
<hbox>
   <button  space-expand="false" space-fill="false">...</button>
   <button  space-expand="false" space-fill="false">...</button>
   <text space-expand="true" space-fill="true"><label>""</label></text>
   <button no></button>
 </hbox>

_________________
http://barryk.org/news/
Back to top
View user's profile Send private message Visit poster's website 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1399
Location: Japan

PostPosted: Wed 23 Aug 2017, 21:54    Post subject:  

BarryK wrote:
Trying exactly as per zigbert's example, there is a problem. I placed the text label after the first three items, but those first three do not pack together at the left side.
They do.
Quote:
They are spread out, as shown in attached photo:
You are mixing up 2 different things. The screenshot indicates that they are glued to the left. That's the purpose of zigbert's example. If you also want the code to prevent their (default) stretching then you would need different code.

Quote:
But then, why have that nested hbox? No need
And when you get rid of the hbox then there's probably no need for all these space-fills either:
Code:
<hbox>
    <button  space-expand="false"></button>
    <button  space-expand="false"></button>
    <text    space-expand="true" label=""></text>
    <button no></button>
</hbox>
Back to top
View user's profile Send private message 
zigbert


Joined: 29 Mar 2006
Posts: 6525
Location: Valåmoen, Norway

PostPosted: Mon 28 Aug 2017, 04:55    Post subject:  

Is it possible to give the <chooser> a predefined name. The path is defined with the <default> option, but I can't find a way to set the default saving filename.
Code:
<chooser action="1" create-folders="true">
 <variable>SAVEFILE</variable>
 <default>'$(dirname "$MYFILE")'</default>
</chooser>
Screenshot.jpg
 Description   
 Filesize   24.61 KB
 Viewed   93 Time(s)

Screenshot.jpg


_________________
Stardust resources
Back to top
View user's profile Send private message Visit poster's website 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1399
Location: Japan

PostPosted: Mon 28 Aug 2017, 06:12    Post subject:  

http://www.murga-linux.com/puppy/viewtopic.php?p=933786#933786
Same question.
Same answer applies.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 80 of 82 [1226 Posts]   Goto page: Previous 1, 2, 3, ..., 78, 79, 80, 81, 82 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1009s ][ Queries: 14 (0.0135s) ][ GZIP on ]