Re: [Patch] for fvwm-menu-desktop
Thomas Adam writes: > Hey Dan, > > On Thu, Jun 21, 2012 at 09:10:19PM -0400, Dan Espen wrote: >> Thomas, >> >> I have no clue about the automake implications of adding python. >> I see how our configure.ac does the perl checking but I'm not clear >> on how to do something similar for python. >> >> I can check in with the #! hard coded to /usr/bin/python. >> Can you clean this up after I do that? > > No problem. Let me know when you've something for me to look at. That post was from before the actual check in. I decided it wouldn't hurt me to learn a little automake. Still pending is checking for the python xdg package. Regarding adding a python dependency, seems to me that's not a big problem. As long as it can be easily bypassed. I guess I haven't done anything for that either. -- Dan Espen
Re: [Patch] for fvwm-menu-desktop
Hey Dan,
On Thu, Jun 21, 2012 at 09:10:19PM -0400, Dan Espen wrote:
> Thomas,
>
> I have no clue about the automake implications of adding python.
> I see how our configure.ac does the perl checking but I'm not clear
> on how to do something similar for python.
>
> I can check in with the #! hard coded to /usr/bin/python.
> Can you clean this up after I do that?
No problem. Let me know when you've something for me to look at.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
Re: [Patch] for fvwm-menu-desktop
Dan Espen writes: > Thomas Adam writes: > >> On Thu, Jun 21, 2012 at 11:41:10AM -0400, Dan Espen wrote: >>> Thomas Funk writes: >>> >>> >> Hmm. I am not sure I agree with this at all. The spec defines >>> >> XDG_MENU_PREFIX which we can carry on using, seeing as its use defines >>> >> more >>> >> than just menus for us -- it's also compliant with other applications >>> >> generating menus; they too look at the value of this. >>> > It changes only the local variable not the ENV >>> > >>> >> Also, why the change of $root_menu to $xdg_menu? That's noise for no >>> >> reason. >>> > because it is more correct - it's not a root menu, it's an application >>> > menu based on the xdg menu ... but can be changed back. >>> >>> I have a rewrite of fvwm-menu-desktop that I've been using for a while >>> now. >>> >>> One of the reasons I haven't released it is because of this distinction. >>> >>> It looks to me like xdg does not include the concept of one root menu. >> >> Well don't let this be a reason to hold you back, Dan. :) I sure as hell >> don't want Thomas to waste his time (and what is infinitely worse through >> this, my time as well) on flogging a dead horse. > > Thomas, > > I have no clue about the automake implications of adding python. > I see how our configure.ac does the perl checking but I'm not clear > on how to do something similar for python. > > I can check in with the #! hard coded to /usr/bin/python. > Can you clean this up after I do that? Backed up mail finally came through. Obviously past this point... -- Dan Espen
Re: [Patch] for fvwm-menu-desktop
Thomas Adam writes: > On Thu, Jun 21, 2012 at 11:41:10AM -0400, Dan Espen wrote: >> Thomas Funk writes: >> >> >> Hmm. I am not sure I agree with this at all. The spec defines >> >> XDG_MENU_PREFIX which we can carry on using, seeing as its use defines >> >> more >> >> than just menus for us -- it's also compliant with other applications >> >> generating menus; they too look at the value of this. >> > It changes only the local variable not the ENV >> > >> >> Also, why the change of $root_menu to $xdg_menu? That's noise for no >> >> reason. >> > because it is more correct - it's not a root menu, it's an application >> > menu based on the xdg menu ... but can be changed back. >> >> I have a rewrite of fvwm-menu-desktop that I've been using for a while >> now. >> >> One of the reasons I haven't released it is because of this distinction. >> >> It looks to me like xdg does not include the concept of one root menu. > > Well don't let this be a reason to hold you back, Dan. :) I sure as hell > don't want Thomas to waste his time (and what is infinitely worse through > this, my time as well) on flogging a dead horse. Thomas, I have no clue about the automake implications of adding python. I see how our configure.ac does the perl checking but I'm not clear on how to do something similar for python. I can check in with the #! hard coded to /usr/bin/python. Can you clean this up after I do that? -- Dan Espen
Re: [Patch] for fvwm-menu-desktop
Thomas Adam writes: > On Thu, Jun 21, 2012 at 11:41:10AM -0400, Dan Espen wrote: >> Thomas Funk writes: >> >> >> Hmm. I am not sure I agree with this at all. The spec defines >> >> XDG_MENU_PREFIX which we can carry on using, seeing as its use defines >> >> more >> >> than just menus for us -- it's also compliant with other applications >> >> generating menus; they too look at the value of this. >> > It changes only the local variable not the ENV >> > >> >> Also, why the change of $root_menu to $xdg_menu? That's noise for no >> >> reason. >> > because it is more correct - it's not a root menu, it's an application >> > menu based on the xdg menu ... but can be changed back. >> >> I have a rewrite of fvwm-menu-desktop that I've been using for a while >> now. >> >> One of the reasons I haven't released it is because of this distinction. >> >> It looks to me like xdg does not include the concept of one root menu. > > Well don't let this be a reason to hold you back, Dan. :) Okay, finally took some time to get this closer to completion. No documentation update yet, but it _should_ just work. It's a bit slower but the new version is massively smaller than the old version. -- Dan Espen
Re: icon title in 2.6.5 changed to window title
On Sat, Jun 16, 2012 at 12:30 (+0100), Thomas Adam wrote: > On Wed, Jun 13, 2012 at 01:34:46PM -0300, Jim Diamond wrote: >> On Thu, 31 May 2012 12:26:34 -0700 Thomas Adam wrote >>> On 31 May 2012 18:11, wrote: P.S. Yes, I know I can work around this bug with a Style * IconTitle %i line in my config. >>> And this is *precisely* why this can never be the default, due to how >>> icon title assignment works. >> Sorry, I don't follow what you are saying. Previously (2.6.1 and back >> for the last 15 or 20 years, as far as I recall) the icon title was > Uh-huh. Was that supposed to be useful? >> the icon title, and now the icon title is (by default) set when the >> window title is set. You say "it can't be done", but changing the > No, never did I say "it can't be done", Is playing with words here helpful? By "done" I meant "be the default", and you did say (see above) that "this can never be the default". What I would like to understand is *why* it can't be the default, given that it was for a long time. > moreover, I said that it won't change to how it is implemented _now_ What does that mean? Nothing needs to change to become what it currently is. > -- and that -- despite the change, you'll have to add in an explicit > IconTitleFormat of "%i" to get the old behaviour to work. > Why isn't this the default? Because not every program has an explicit icon > title -- and since the XEvent queue can't guarantee when FVWM proceeses a > WM_NAME event from an icon title event (few programs actually set explicit > icon titles; xterm is one which does though), setting the icon title to its > window name in the general case covers that, and those people who know a > program has the ability to change its icon title can just set "%i" for their > IconTitleFormat string. Notwithstanding this explanation, I can't say I ever noticed a problem with older versions of fvwm (vis-a-vis icon titles). I'm curious about what problems people were having that require a non-backward-compatible change to fvwm. If people were ending up with icons with no titles, would it not have been possible to make the default behaviour to use the icon title when there was one, and if not use the window title? Jim
Re: [Patch] Fixing bugs and some improvements for fvwm-menu-desktop.in
2012/6/25 Dan Espen :
>> - some menu entries doesn't work because of these trailing %U, %f,
>> etc. Therefore these parts must be eliminated:
>> Fix in parsemenu():
>> m = re.compile('%[A-Z]?', re.I)
>> :
>> execProgram = m.sub('', desktop.getExec())
>
> Applied but I'm not so sure removing %A-Za-z from all exec commands
> is a good idea. Isn't there a more limited set of these?
I don't know. Must check. But as I compare the menu created by the old
fvwm-menu-desktop the exec commands look the same...
>> some icons defined in the desktop files won't be created because they
>> are svgs. But convert can't convert to .svg
>> Fix in geticonfile() to convert also svgs:
>> if not iconpath == None:
>> extension = os.path.splitext(iconpath)[1]
>> :
>> if extension == '.svg':
>> iconfile = iconfile.replace('.svg', '.png')
>
> If the icon called for is svg, why does this code assume
> there will be a .png file? Not applied yet.
No no ... the iconfile is the destination created from the basename of
the source (iconpath):
iconfile = os.path.join(os.path.expanduser(options.icon_dir),
"%ix%i-" % (size, size) +
os.path.basename(iconpath))
Convert needs a bitmap extension, otherwise an error occur. It cannot
convert a svg TO .svg but to png
Therefore I changed the extension of the iconfile.
>> These fixes let the tool run in eclipse smoothless. But not on the
>> command line.
>> #!@PYTHON@
>> doesn't work there. Switched back to
>> #!/usr/bin/python
>
> Run the whole automake sequence and this should clear up.
Ah, ok. haven't compiled it yet.
Btw. did you have implemented a query for ./configure for python-xdg?
I used this in an sh install script:
module_found=`python -c "import xdg" 2>/dev/null && echo "1"`
if [ "$module_found" == "" ]
then
echo -e "not found"
else
echo -e "found"
fi
> Sure appreciate the help.
You're welcome :-)
Thomas
Re: CVS dane: * commands/Style.xml: Cleanup iconsize.
On Fri, Jun 22, 2012 at 10:12:07AM -0500, c...@math.uh.edu wrote: > * configure.ac: Set variables for python. > * fvwm-menu-desktop.in: > Rewrite using python and xdg libs. Please do not let me forget that when I release the next version of FVWM (which will not be any time soon), I make a big song and dance about this. FVWM will (unfortunately) now rely on both perl *AND* python to function, pulling in python plus additional libraries. -- Thomas Adam
