Menu
▾
▴
fvwm-themes-devel — Developing FVWM Themes
You can subscribe to this list here.
| 2000 |
Jan
(40) |
Feb
(57) |
Mar
(31) |
Apr
(62) |
May
(15) |
Jun
(38) |
Jul
(46) |
Aug
(50) |
Sep
(13) |
Oct
(41) |
Nov
(65) |
Dec
(36) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(15) |
Feb
(50) |
Mar
(57) |
Apr
(10) |
May
(24) |
Jun
(10) |
Jul
(14) |
Aug
(20) |
Sep
(9) |
Oct
(32) |
Nov
(4) |
Dec
(3) |
| 2002 |
Jan
|
Feb
(8) |
Mar
(3) |
Apr
(3) |
May
(15) |
Jun
(23) |
Jul
(11) |
Aug
|
Sep
(6) |
Oct
(7) |
Nov
|
Dec
(30) |
| 2003 |
Jan
(8) |
Feb
(5) |
Mar
(4) |
Apr
(9) |
May
(11) |
Jun
|
Jul
(5) |
Aug
|
Sep
(22) |
Oct
(30) |
Nov
(13) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(2) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(1) |
Feb
|
Mar
(12) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(10) |
Oct
|
Nov
|
Dec
(4) |
|
From: Olivier C. <oli...@fr...> - 2001-02-26 08:44:26
|
Andre Goeree wrote: > > On Sun, Feb 25, 2001 at 08:56:48PM +0100, Olivier Chapuis wrote: > 11197 > 11196 > 1 > Not set > Not set > Not set > > There's always a difference of 1 between the two pids. > > > > > Interseting, is the second pid is the pid of the Test > > FvwmScript? > > Yes. > So, we have found how to fix the problem :o) I've just commited this fix. Can you try it (of course you need to rereplace the 1 by the 0 in the my $test = 0/1 line in the perl scripts). The problem was that with BSD popen execute the command as sh -c "command" and that with Linux popen execute the command with sh -c "exec command" (or someting like that). As exec exec command is the same thing that exec command we get a fix for all POSIX os by replacing perl -e 'print getppid . "\n"' by exec perl -e 'print getppid . "\n"' Now we can try to work on the core dump ... Thanks again, Olivier |
|
From: Andre G. <abg...@uw...> - 2001-02-25 23:44:50
|
On Sun, Feb 25, 2001 at 08:56:48PM +0100, Olivier Chapuis wrote:
> Andre Goeree wrote:
> >
> > On Fri, Feb 23, 2001 at 09:46:49PM +0100, Olivier Chapuis wrote:
> > > Andre Goeree wrote:
> > > >
> > > > On Fri, Feb 23, 2001 at 10:23:12AM +0100, Olivier Chapuis wrote:
> > > > > Andre Goeree wrote:
> > > > >
> > > > > Yes
> > > > Good! :-)
> > > > >
> > > > > > ago@mandark$ ls -a ~/.fvwm/.tmp-com-*
> > > > > > .tmp-com-lock-script-16049
> > > > > >
> > > > > > And "ps" gives:
> > > > > > 16047 /home/ago/sys/fvwm/libexec/fvwm/2.3.29/FvwmScript ...
> > > > > >
> > > > >
> > > > > The commands use by the FvwmScript scripts to found the pid
> > > > > is:
> > > > >
> > > > > Set $cmd = {perl -e '$t=getppid; print $t . "\n"'}
> > > > > Set $pid = (GetOutput $cmd 1 -1)
> > > > >
> > > > > FvwmScript use popen (and fread) to get the output.
> > > > > It seems that on Andre machine the following happen:
> > > > >
> > > > > FvwmScript -> a shell run by popen -> perl cmd
> > > > >
> > > >
> > > > Yes, this appears to be the case, from the popen(3) man page:
> > > > DESCRIPTION
> > > [snip]
> > > >
> > > > There you have it :-)
> > > >
> > >
> > > Yes, but the description of popen of my glibc is almost the same
> > > and the result is different ...
> >
> > Hmm, i've been busy setting up a Linux box (Mandrake 6.1) so
> > that i will have reference, it has been a long time ago that
> > i've seen a penguin :-) This way it will be easier for me/us
> > to point out the differences.
> > Now that i studied the Linux popen(3) man page, there's indeed
> > (almost) no difference between the two pages...
> > I will study/compare some more of the related man pages to
> > see if i can find what where looking for.
> >
> > > Any way if you want to use the Themes Center ...etc. you
> > > can use the "Second Experience".
> >
> > I modified the scripts as you asked and re-installed the
> > stuff. The output of the Test script:
> > 11197
> > 11196
> > 1
> > Not set
> > Not set
> > Not set
> >
> > There's always a difference of 1 between the two pids.
> >
>
> Interseting, is the second pid is the pid of the Test
> FvwmScript?
Yes.
>
> > I can run both Themes and Config Center. The Menu Editor
> > also works. What stays is the difference between the pid
> > and the .tmp-com* files... There was no need to kill the
> > scripts by hand.
> >
>
> Yes, if you use the quit button of the GUI. But if you kill the
> GUI with an other procedure (say, kill -9 pid_of_the_FvwmScript),
> then you need to kill the perl script by hand.
>
> Regards, Olivier
>
>
>
> > Hope this helps you a little further.
> >
> > Andre.
> >
> > --
> > FVWM-Themes-devel mailing list, fvw...@li...
> > http://lists.sourceforge.net/lists/listinfo/fvwm-themes-devel
>
> --
> FVWM-Themes-devel mailing list, fvw...@li...
> http://lists.sourceforge.net/lists/listinfo/fvwm-themes-devel
>
--
|
|
From: Olivier C. <oli...@fr...> - 2001-02-25 21:55:36
|
Andre Goeree wrote:
>
> On Fri, Feb 23, 2001 at 09:46:49PM +0100, Olivier Chapuis wrote:
> > Andre Goeree wrote:
> > >
> > > On Fri, Feb 23, 2001 at 10:23:12AM +0100, Olivier Chapuis wrote:
> > > > Andre Goeree wrote:
> > > >
> > > > Yes
> > > Good! :-)
> > > >
> > > > > ago@mandark$ ls -a ~/.fvwm/.tmp-com-*
> > > > > .tmp-com-lock-script-16049
> > > > >
> > > > > And "ps" gives:
> > > > > 16047 /home/ago/sys/fvwm/libexec/fvwm/2.3.29/FvwmScript ...
> > > > >
> > > >
> > > > The commands use by the FvwmScript scripts to found the pid
> > > > is:
> > > >
> > > > Set $cmd = {perl -e '$t=getppid; print $t . "\n"'}
> > > > Set $pid = (GetOutput $cmd 1 -1)
> > > >
> > > > FvwmScript use popen (and fread) to get the output.
> > > > It seems that on Andre machine the following happen:
> > > >
> > > > FvwmScript -> a shell run by popen -> perl cmd
> > > >
> > >
> > > Yes, this appears to be the case, from the popen(3) man page:
> > > DESCRIPTION
> > [snip]
> > >
> > > There you have it :-)
> > >
> >
> > Yes, but the description of popen of my glibc is almost the same
> > and the result is different ...
>
> Hmm, i've been busy setting up a Linux box (Mandrake 6.1) so
> that i will have reference, it has been a long time ago that
> i've seen a penguin :-) This way it will be easier for me/us
> to point out the differences.
> Now that i studied the Linux popen(3) man page, there's indeed
> (almost) no difference between the two pages...
> I will study/compare some more of the related man pages to
> see if i can find what where looking for.
>
> > Any way if you want to use the Themes Center ...etc. you
> > can use the "Second Experience".
>
> I modified the scripts as you asked and re-installed the
> stuff. The output of the Test script:
> 11197
> 11196
> 1
> Not set
> Not set
> Not set
>
> There's always a difference of 1 between the two pids.
>
Interseting, is the second pid is the pid of the Test
FvwmScript?
> I can run both Themes and Config Center. The Menu Editor
> also works. What stays is the difference between the pid
> and the .tmp-com* files... There was no need to kill the
> scripts by hand.
>
Yes, if you use the quit button of the GUI. But if you kill the
GUI with an other procedure (say, kill -9 pid_of_the_FvwmScript),
then you need to kill the perl script by hand.
Regards, Olivier
> Hope this helps you a little further.
>
> Andre.
>
> --
> FVWM-Themes-devel mailing list, fvw...@li...
> http://lists.sourceforge.net/lists/listinfo/fvwm-themes-devel
|
|
From: Mikhael G. <mi...@ho...> - 2001-02-25 16:42:57
|
On 25 Feb 2001 15:20:58 +1030, Alex Wallis wrote: > > Mikhael Goikhman wrote: > > > > Unfortunatelly, I can't see why some mini icons don't work for you, the > > ImagePath seems ok. I also can't reproduce any problem. You should help. > > You're absolutely correct, and I apologise if you've wasted time on > this. > > So I played about with it. Incidently in the process I found that the > Themes-Center GUI worked perfectly for me. :) > > So I reset All to Default, then selected awol/All and everything was > fine. > After much experimentation, I found if you then select settings/KDE > System Menu/ and either Menu & Styles(??x?? icons) the problem occurs. > However the Menu Only option not only leaves my mini icons intact, but > still gives me kde menus with full sets of icons. There are occasional > gaps though. (see attached screenshot) > > I use my kde menu's a lot because I'm still discovering what all this > 5G's of SuSe software does. > > I'm not sure if this is a bug. Perhaps it's just me? No, it is on my machine too. If I choose KDE system menus "Menu & Styles" my normal icons (iconified windows), mini icons (on titles) and menu icons of these KDE menus are broken. This is a KDE feature, they include many inconsistent .directory files and fvwm-menu-desktop script can't do nothing about this. In the near future all (well most) KDE applications will be configured with wm-icons, so "Menu" option will give arguably better results than "Menu & Styles", the first gives themable icons, the second gives original KDE icons (if you have them), the choice is yours. Regards, Mikhael. |
|
From: Andre G. <abg...@uw...> - 2001-02-25 08:00:56
|
On Fri, Feb 23, 2001 at 09:46:49PM +0100, Olivier Chapuis wrote:
> Andre Goeree wrote:
> >
> > On Fri, Feb 23, 2001 at 10:23:12AM +0100, Olivier Chapuis wrote:
> > > Andre Goeree wrote:
> > >
> > > Yes
> > Good! :-)
> > >
> > > > ago@mandark$ ls -a ~/.fvwm/.tmp-com-*
> > > > .tmp-com-lock-script-16049
> > > >
> > > > And "ps" gives:
> > > > 16047 /home/ago/sys/fvwm/libexec/fvwm/2.3.29/FvwmScript ...
> > > >
> > >
> > > The commands use by the FvwmScript scripts to found the pid
> > > is:
> > >
> > > Set $cmd = {perl -e '$t=getppid; print $t . "\n"'}
> > > Set $pid = (GetOutput $cmd 1 -1)
> > >
> > > FvwmScript use popen (and fread) to get the output.
> > > It seems that on Andre machine the following happen:
> > >
> > > FvwmScript -> a shell run by popen -> perl cmd
> > >
> >
> > Yes, this appears to be the case, from the popen(3) man page:
> > DESCRIPTION
> [snip]
> >
> > There you have it :-)
> >
>
> Yes, but the description of popen of my glibc is almost the same
> and the result is different ...
Hmm, i've been busy setting up a Linux box (Mandrake 6.1) so
that i will have reference, it has been a long time ago that
i've seen a penguin :-) This way it will be easier for me/us
to point out the differences.
Now that i studied the Linux popen(3) man page, there's indeed
(almost) no difference between the two pages...
I will study/compare some more of the related man pages to
see if i can find what where looking for.
> Any way if you want to use the Themes Center ...etc. you
> can use the "Second Experience".
I modified the scripts as you asked and re-installed the
stuff. The output of the Test script:
11197
11196
1
Not set
Not set
Not set
There's always a difference of 1 between the two pids.
I can run both Themes and Config Center. The Menu Editor
also works. What stays is the difference between the pid
and the .tmp-com* files... There was no need to kill the
scripts by hand.
Hope this helps you a little further.
Andre.
|
|
From: Mikhael G. <mi...@ho...> - 2001-02-25 02:14:33
|
Unfortunatelly, I can't see why some mini icons don't work for you, the ImagePath seems ok. I also can't reproduce any problem. You should help. Please take some icon, which does not work. Tell us which component this icon belongs to, say, buttons@awol or KDE system menus, or your own. Send us as much info as possible, try to determine what the icon name is used, whether there are any error messages in console, which command is used to generate this icon (if this is a dynamic menu for example). If you think a screenshot will help, send it. > The images are there, it seems the Default ImagePath is what's failing. The Default ImagePath, that you see in --info, is not used in fvwm-themes. Do you use icons from this path in your own personal theme components? Regards, Mikhael. |
|
From: Alex W. <aw...@do...> - 2001-02-24 03:29:16
|
Sorry! I misunderstood.
Mikhael Goikhman wrote:
>
> On 23 Feb 2001 22:07:22 +1030, Alex Wallis wrote:
> >
> > Mikhael Goikhman wrote:
> > >
> > > On 23 Feb 2001 03:02:18 +1030, Alex Wallis wrote:
> > > >
> > > > Did I mention that most of my mini-icons disappeared awhile ago?
> > >
> > > Send the output of the following (the second requires an updated CVS):
> > >
> > > fvwm-themes-config --expand-rc | egrep '(ImagePath|SetEnv FT_DATADIR)'
> > > fvwm-themes-config --info
> >
>
> No, I meant:
>
> cvs update
> make install
> fvwm-themes-config --info
OK. Got it now. Here's the result....
awol@awol:~/.fvwm > fvwm-themes-config --info
Package: fvwm-themes
Version: 0.4.2
FVWM version when this package was built: 2.3.29
Instalation options:
prefix: /opt/fvwm
bindir: /opt/fvwm/bin
datadir: /opt/fvwm/share
mandir: /opt/fvwm/man
Built-in paths:
Data directory: /opt/fvwm
Default UserDir: /home/awol/.fvwm
Default ImagePath:
/usr/include/X11/bitmaps:/usr/include/X11/pixmaps
>
> > > Which from your mini icons are disappeared, which are not?
> >
> > Nearly all except a handful of kde icons and any in
> > $FVWM_USERDIR/images:$FT_DATADIR/images
> > So basically the compiled in ImagePaths are the ones not working.
>
> Sorry to be so dumb, but I still don't understand, which icons don't work.
> Icons from menus, from buttonbars, mini-icons on titles or something else?
>
The mini icons are missing from FvwmIconMan and FvwmPager and TitleBars
also.
The menu mini icons however are present, except in my SuSe menu's for
everything installed on my box. Only the folder mini icon is present in
the SuSe menus.
However the fvwm-themes menus have their mini icons.
> Can you please verify whether the icons which do not work are present or
> absent in all ImagePath directories?
>
The images are there, it seems the Default ImagePath is what's failing.
Alex
|
|
From: Olivier C. <oli...@fr...> - 2001-02-23 20:48:28
|
Mikhael Goikhman wrote: > > On 19 Feb 2001 21:17:51 +0100, Olivier Chapuis wrote: > > > > Mikhael Goikhman wrote: > > > > > > Olivier, I have some questions about how we divide our tasks. > > > > > > 1) On wm-icons I can work (as time allows) on all existing icon sets, but > > > maybe you had plans to work on them too? > > > > Yes and no, I've a lot of 16x16-general and kde icons like on my machine, > > so if you have gap I may help. > > Hmm, but if I do all the work, you will not really feel how is it to > manage thousand of icons. :) Most of which should be redocumented, > probably renamed, replaced, fixed and so on. Ok, I will transform all > icon sets to our new icon list. But after that I need a help in polishing. > But you say "I can work (as time allows) on all existing icon sets ..." If you want I can do 16x16-general, 14x14-general, and *-kde2. Of course, as usuall, we will check/fix the work of the other. > > Also, I've planed to add gnome icons (16x16-gnome is almost finished). > > Finally, I would like to reworte fvwm-themes-menuapp (a script for > > (re)building programs menu and (mini)icon styles). But, this need > > discussion; e;g., > > a - where to put this script? In wm-icons, in fvwm-themes, in both? > > Probably in both, by a different names. Alternatively, we may simply add a > wm-icons requirement for fvwm-themes, this really would add themability, > but I don't know how users will like this. There are already 2 packages > to install (fvwm and fvwm-themes), and wm-icons is currently optional. > I think that it is preferable to do not add a dependence to wm-icons in fvwm-themes. So a priorie "both" is the answer. But, the task is probably different: fvwm-themes need config file for fvwm and fvwm-themes as wm-icons need config file for all window manager. > > b - what kind of data base we have to use? > > I would not spend time now to develop a new data base, maybe later. > Currently we may continue with wm-icons/devel/conf/style-icons.cfg . > > > c - do we have to start a new project: wm-db? > > No, not now. > > > d - can we use debian system menu? > > What exactly does this mean? And how debian system menu is better than RH > wmconfig? If this means we should have additional mandatory dependancy, > I would rather continue with our current approach about application menus. > debian system menu is very good. You can generate config file (with icons) for menu or icon style (or even FvwmButtons like apps) for any window manager. You have a config file for each file you want to produce which is a kind of script language. So, really you can generate config file for wm that will exist! The only problem is the applications data base which is distribution dependent. Any way, I think that we have to do our own tools but the debian system menu is good example to look at. Regards, Olivier |
|
From: Olivier C. <oli...@fr...> - 2001-02-23 20:48:28
|
Andre Goeree wrote:
>
> On Fri, Feb 23, 2001 at 10:23:12AM +0100, Olivier Chapuis wrote:
> > Andre Goeree wrote:
> >
> > Yes
> Good! :-)
> >
> > > ago@mandark$ ls -a ~/.fvwm/.tmp-com-*
> > > .tmp-com-lock-script-16049
> > >
> > > And "ps" gives:
> > > 16047 /home/ago/sys/fvwm/libexec/fvwm/2.3.29/FvwmScript ...
> > >
> >
> > The commands use by the FvwmScript scripts to found the pid
> > is:
> >
> > Set $cmd = {perl -e '$t=getppid; print $t . "\n"'}
> > Set $pid = (GetOutput $cmd 1 -1)
> >
> > FvwmScript use popen (and fread) to get the output.
> > It seems that on Andre machine the following happen:
> >
> > FvwmScript -> a shell run by popen -> perl cmd
> >
>
> Yes, this appears to be the case, from the popen(3) man page:
> DESCRIPTION
[snip]
>
> There you have it :-)
>
Yes, but the description of popen of my glibc is almost the same
and the result is different ...
Any way if you want to use the Themes Center ...etc. you
can use the "Second Experience".
>
> Hmm, i'm afraid that you have to give some instructions
> on how to run the script. I'm not that up to date on the
> matter yet..
>
Unfortunately, this will probably not solve our problem. But
you can copy the Test attached file to ~/.fvwm/test/Test
and run in an FvwmConsole (Fvwm Modules/Start Regular Module/
Console in the menu): FvwmScript test/Test
Regards, Olivier
|
|
From: Andre G. <abg...@uw...> - 2001-02-23 14:50:28
|
On Fri, Feb 23, 2001 at 10:23:12AM +0100, Olivier Chapuis wrote:
> Andre Goeree wrote:
> >
> > ----- Forwarded message from Andre Goeree <abg...@uw...> -----
> >
> > Subject: Re: No more FvwmScript-ThemesCenter: exit!
> > From: Andre Goeree <abg...@uw...>
> > To: Olivier Chapuis <oli...@fr...>
> > Date: Thu, 22 Feb 2001 20:37:52 +0100
> >
> > On Thu, Feb 22, 2001 at 04:30:29PM +0100, Olivier Chapuis wrote:
> > >
> > > First experience: start one of the above FvwmScript. You should
> > > see a .tpm-com-lock-"script_name"-pidnum pipe. Can you check if
> > > the pidnum is good: is this pidnum the pid of the FvwmScript you
> > > start?
> > > If no we have found the bug and you do not need to do the second
> > > experience.
> >
> > I believe we have found it :-)
> >
>
> Yes
Good! :-)
>
> > ago@mandark$ ls -a ~/.fvwm/.tmp-com-*
> > .tmp-com-lock-script-16049
> >
> > And "ps" gives:
> > 16047 /home/ago/sys/fvwm/libexec/fvwm/2.3.29/FvwmScript ...
> >
>
> The commands use by the FvwmScript scripts to found the pid
> is:
>
> Set $cmd = {perl -e '$t=getppid; print $t . "\n"'}
> Set $pid = (GetOutput $cmd 1 -1)
>
> FvwmScript use popen (and fread) to get the output.
> It seems that on Andre machine the following happen:
>
> FvwmScript -> a shell run by popen -> perl cmd
>
Yes, this appears to be the case, from the popen(3) man page:
DESCRIPTION
The popen() function ``opens'' a process by creating a bidirectional pipe
forking, and invoking the shell. Any streams opened by previous popen()
calls in the parent process are closed in the new child process. Histor-
ically, popen() was implemented with a unidirectional pipe; hence many
implementations of popen() only allow the type argument to specify read-
ing or writing, not both. Since popen() is now implemented using a bidi-
rectional pipe, the type argument may request a bidirectional data flow.
The type argument is a pointer to a null-terminated string which must be
`r' for reading, `w' for writing, or `r+' for reading and writing.
The command argument is a pointer to a null-terminated string containing
a shell command line. This command is passed to /bin/sh using the -c
flag; interpretation, if any, is performed by the shell.
There you have it :-)
> so the $pid is the pid a of shell run by popen. However,
> on our Linux machine the shell is hidden so perl return
> the "correct" parent pid. The problem can came from a lot
> of place:
> - the libc (Andre what is your(/bsd) libc?)
libc version 4.0
> - perl implementation
perl 5.005_3, not threaded, no suidperl.
> - os process implementation
> Really no idea.
I searched the system docs for the subject but could
not find anything appropriate yet...
> Mikhael do you have an idea to fix this? We can go back
> to the ps command and try to use it in a POSFIX way (or
> use some "if (linux) then ... else if (bds) ...").
>
> I've done a Test FvwmScript attached to this message,
> to do some tests. Andre can you run it. On my machine
> the first two pid are the FvwmScript pid and the 3rd
> is the init pid (1). There are almost no hope that the
> second pid number will solve our problems.
Hmm, i'm afraid that you have to give some instructions
on how to run the script. I'm not that up to date on the
matter yet..
Regards,
Andre
|
|
From: Mikhael G. <mi...@ho...> - 2001-02-23 12:40:19
|
On 23 Feb 2001 22:07:22 +1030, Alex Wallis wrote: > > Mikhael Goikhman wrote: > > > > On 23 Feb 2001 03:02:18 +1030, Alex Wallis wrote: > > > > > > Did I mention that most of my mini-icons disappeared awhile ago? > > > > Send the output of the following (the second requires an updated CVS): > > > > fvwm-themes-config --expand-rc | egrep '(ImagePath|SetEnv FT_DATADIR)' > > fvwm-themes-config --info > > The first command resulted in reproducing lines 18,19 and 20 from > themes-rc-2/3 > I sent the results of the above commands to a file > awol-test-file.txt(attached) > For the second, I assumed you meant fvwm-config --info :-P No, I meant: cvs update make install fvwm-themes-config --info > > Which from your mini icons are disappeared, which are not? > > Nearly all except a handful of kde icons and any in > $FVWM_USERDIR/images:$FT_DATADIR/images > So basically the compiled in ImagePaths are the ones not working. Sorry to be so dumb, but I still don't understand, which icons don't work. Icons from menus, from buttonbars, mini-icons on titles or something else? Can you please verify whether the icons which do not work are present or absent in all ImagePath directories? Regards, Mikhael. |
|
From: Alex W. <aw...@do...> - 2001-02-23 11:37:23
|
Mikhael Goikhman wrote: > > On 23 Feb 2001 03:02:18 +1030, Alex Wallis wrote: > > > > Did I mention that most of my mini-icons disappeared awhile ago? > > Please do "Refresh the current theme" from the menu. > If this solves the problem, skip the rest. Doesn't help. > > If this does not solve your problem, there is a problem with instalation. > Send the output of the following (the second requires an updated CVS): > > fvwm-themes-config --expand-rc | egrep '(ImagePath|SetEnv FT_DATADIR)' > fvwm-themes-config --info The first command resulted in reproducing lines 18,19 and 20 from themes-rc-2/3 I sent the results of the above commands to a file awol-test-file.txt(attached) For the second, I assumed you meant fvwm-config --info :-P > > Which from your mini icons are disappeared, which are not? > Nearly all except a handful of kde icons and any in $FVWM_USERDIR/images:$FT_DATADIR/images So basically the compiled in ImagePaths are the ones not working. Strangely though, the icons I have now were always missing before but I never bothered to find out why. Alex |
|
From: Mikhael G. <mi...@ho...> - 2001-02-23 11:32:16
|
On 23 Feb 2001 05:23:48 -0600, Mikhael Goikhman wrote: > > > b - what kind of data base we have to use? > > I would not spend time now to develop a new data base, maybe later. > Currently we may continue with wm-icons/devel/conf/style-icons.cfg . I wanted to say: fvwm-themes/themes/default/menus-user . :) I agree we should have a better format, but do we have a time now? Regards, Mikhael. |
|
From: Mikhael G. <mi...@ho...> - 2001-02-23 11:23:50
|
On 19 Feb 2001 21:17:51 +0100, Olivier Chapuis wrote: > > Mikhael Goikhman wrote: > > > > Olivier, I have some questions about how we divide our tasks. > > > > 1) On wm-icons I can work (as time allows) on all existing icon sets, but > > maybe you had plans to work on them too? > > Yes and no, I've a lot of 16x16-general and kde icons like on my machine, > so if you have gap I may help. Hmm, but if I do all the work, you will not really feel how is it to manage thousand of icons. :) Most of which should be redocumented, probably renamed, replaced, fixed and so on. Ok, I will transform all icon sets to our new icon list. But after that I need a help in polishing. > Also, I've planed to add gnome icons (16x16-gnome is almost finished). > Finally, I would like to reworte fvwm-themes-menuapp (a script for > (re)building programs menu and (mini)icon styles). But, this need > discussion; e;g., > a - where to put this script? In wm-icons, in fvwm-themes, in both? Probably in both, by a different names. Alternatively, we may simply add a wm-icons requirement for fvwm-themes, this really would add themability, but I don't know how users will like this. There are already 2 packages to install (fvwm and fvwm-themes), and wm-icons is currently optional. > b - what kind of data base we have to use? I would not spend time now to develop a new data base, maybe later. Currently we may continue with wm-icons/devel/conf/style-icons.cfg . > c - do we have to start a new project: wm-db? No, not now. > d - can we use debian system menu? What exactly does this mean? And how debian system menu is better than RH wmconfig? If this means we should have additional mandatory dependancy, I would rather continue with our current approach about application menus. Regards, Mikhael. |
|
From: Mikhael G. <mi...@ho...> - 2001-02-23 10:49:51
|
On 23 Feb 2001 03:02:18 +1030, Alex Wallis wrote: > > Did I mention that most of my mini-icons disappeared awhile ago? Please do "Refresh the current theme" from the menu. If this solves the problem, skip the rest. If this does not solve your problem, there is a problem with instalation. Send the output of the following (the second requires an updated CVS): fvwm-themes-config --expand-rc | egrep '(ImagePath|SetEnv FT_DATADIR)' fvwm-themes-config --info Which from your mini icons are disappeared, which are not? Regards, Mikhael. |
|
From: Olivier C. <oli...@fr...> - 2001-02-23 09:23:18
|
Andre Goeree wrote:
>
> ----- Forwarded message from Andre Goeree <abg...@uw...> -----
>
> Subject: Re: No more FvwmScript-ThemesCenter: exit!
> From: Andre Goeree <abg...@uw...>
> To: Olivier Chapuis <oli...@fr...>
> Date: Thu, 22 Feb 2001 20:37:52 +0100
>
> On Thu, Feb 22, 2001 at 04:30:29PM +0100, Olivier Chapuis wrote:
> >
> > First experience: start one of the above FvwmScript. You should
> > see a .tpm-com-lock-"script_name"-pidnum pipe. Can you check if
> > the pidnum is good: is this pidnum the pid of the FvwmScript you
> > start?
> > If no we have found the bug and you do not need to do the second
> > experience.
>
> I believe we have found it :-)
>
Yes
> ago@mandark$ ls -a ~/.fvwm/.tmp-com-*
> .tmp-com-lock-script-16049
>
> And "ps" gives:
> 16047 /home/ago/sys/fvwm/libexec/fvwm/2.3.29/FvwmScript ...
>
The commands use by the FvwmScript scripts to found the pid
is:
Set $cmd = {perl -e '$t=getppid; print $t . "\n"'}
Set $pid = (GetOutput $cmd 1 -1)
FvwmScript use popen (and fread) to get the output.
It seems that on Andre machine the following happen:
FvwmScript -> a shell run by popen -> perl cmd
so the $pid is the pid a of shell run by popen. However,
on our Linux machine the shell is hidden so perl return
the "correct" parent pid. The problem can came from a lot
of place:
- the libc (Andre what is your(/bsd) libc?)
- perl implementation
- os process implementation
Really no idea.
Mikhael do you have an idea to fix this? We can go back
to the ps command and try to use it in a POSFIX way (or
use some "if (linux) then ... else if (bds) ...").
I've done a Test FvwmScript attached to this message,
to do some tests. Andre can you run it. On my machine
the first two pid are the FvwmScript pid and the 3rd
is the init pid (1). There are almost no hope that the
second pid number will solve our problems.
Regards, Olivier |
|
From: Andre G. <abg...@uw...> - 2001-02-23 08:22:34
|
----- Forwarded message from Andre Goeree <abg...@uw...> ----- Subject: Re: No more FvwmScript-ThemesCenter: exit! From: Andre Goeree <abg...@uw...> To: Olivier Chapuis <oli...@fr...> Date: Thu, 22 Feb 2001 20:37:52 +0100 On Thu, Feb 22, 2001 at 04:30:29PM +0100, Olivier Chapuis wrote: > > First experience: start one of the above FvwmScript. You should > see a .tpm-com-lock-"script_name"-pidnum pipe. Can you check if > the pidnum is good: is this pidnum the pid of the FvwmScript you > start? > If no we have found the bug and you do not need to do the second > experience. I believe we have found it :-) ago@mandark$ ls -a ~/.fvwm/.tmp-com-* .tmp-com-lock-script-16049 And "ps" gives: 16047 /home/ago/sys/fvwm/libexec/fvwm/2.3.29/FvwmScript ... And i had to be quick to catch it, the .tmp-com* files disappear shortly after "Themes Configuration Center" (how i tested the above) is started. I also tried "Menu Editor". In all cases the pidnums always slightly differed from each-other, every time i saw it. Yes, this must be it. -- Andre. ----- End forwarded message ----- |
|
From: Alex W. <aw...@do...> - 2001-02-22 16:32:17
|
Alex Wallis wrote: > > For some time since Olivier began the locale languages thing, I have > been missing the writing on the FvwmScript GUI's buttons. See attached > images. > I'm happy to announce this appears to be fixed now with Mikhael's latest commit. :) Did I mention that most of my mini-icons disappeared awhile ago? Alex |
|
From: Olivier C. <oli...@fr...> - 2001-02-22 15:30:36
|
Andre Goeree wrote: > > > The perl examples work as you described: > > ago@mandark$ perl --version > This is perl, version 5.005_03 built for i386-freebsd > > ago@mandark$ perl -e 'print "OK\n" if kill 0 => 1023' > OK > ago@mandark$ perl -e 'kill 9 => 1023' > Killed > (and the program gets killed) > Hum, so the kill perl command is ok. The fvwm-themes FvwmScript which cause problems (No more ...) use named pipes to communicate with a perl script, these pipe are in your FVWM_USERHOME (~/.fvwm/ by default) and are named: .tmp-com-"type"-"script_name"-pidnum where "type" can be lock, out or in, where script_name is config with the Theme Center, script with the Config Center and menuapp with the Menu Editor (so there are the name of the perl script which run in the background minus fvwm-themes-). Finally, pidnum is the PID of the *FvwmScript*. Ok, you probably already know all these. Now can you do the following: First, remove all the .tmp-com-* pipe (assuming that no of the above script run on your machine). Normally, these pipe are removed but since you've got some crash it is possible that some were not (but this should not cause problems). Also, check if fvwm-themes-config, fvwm-themes-menuapp or fvwm-themes-script run (this can cause problem in exceptional situation only). First experience: start one of the above FvwmScript. You should see a .tpm-com-lock-"script_name"-pidnum pipe. Can you check if the pidnum is good: is this pidnum the pid of the FvwmScript you start? If no we have found the bug and you do not need to do the second experience. Second experience: cd to bin/ in the fvwm-themes source. Then, edit fvwm-themes-config.in, fvwm-themes-menuapp.in or/and fvwm-themes-script.in: go to the line: my $test = 0; in checkScript sub (there is only one line of this type in config and script, two in menuapp but you will find the good one). And change the 0 by a 1. Then, make install and try again the script. Do they work? Here a warning, if the FvwmScript quit abnormally then the corresponding perl script will continue to run so you have to kill it by hands. Maybe, try first with the Config Center and the Themes Center. The Menu Editor is secondary (it was also my first try (a kind of experimentation) for communication between a perl script and a FvwmScript). Thanks a lot, Olivier |
|
From: Andre G. <abg...@uw...> - 2001-02-21 11:16:54
|
On Wed, Feb 21, 2001 at 12:18:21AM +0100, Olivier Chapuis wrote: > Thanks for the report. > About, The FvwmScript scripts (Theme and Config Center and the > Menu editor) it seems that the perl command "kill" does not work > on your bsd machine (or is not used in the good way). > Andre, can you try the following. Open an application, say an xterm, > see which is the PID of this app. Say that it is pidnum. Then, try > > perl -e 'print "OK\n" if kill 0 => pidnum' > > this should print OK. > > perl -e 'kill 9 => pidnum' > > this should kill your app. > > About the problems that cause core, it seems to me that these > problems are FVWM problems. What version of FVWM do you use? > I strongly encourage you to use 2.3.28 and 2.3.29 when this > version will be out (this version will be very close from 2.4). > > Thanks, Olivier Hello Olivier, I'm glad to hear that my report was useful and that we're getting closer to the source of the problem :-) The perl examples work as you described: ago@mandark$ perl --version This is perl, version 5.005_03 built for i386-freebsd ago@mandark$ perl -e 'print "OK\n" if kill 0 => 1023' OK ago@mandark$ perl -e 'kill 9 => 1023' Killed (and the program gets killed) My fvwm version (sorry, i forgot to mention): FVWM version 2.3.29 compiled on Feb 19 2001 at 20:43:46 with support for: ReadLine, XPM, GNOME WM hints, SM I "cvs update" fvwm and fvwm-themes on a regular basis now while i cvsup the FreeBSD source code and ports, which is at least once a week. Hmm, regarding the core dumps, i saw symbols of ibXThrStub.so.6 getting loaded when i loaded the core files in my debugger. There's currently something going on about -pthread (threads) in the ports mailing list, by insiders called the "-pthread weirdness". I believe this also affects Xthreads in XFree86-4.0.2 which i'm using, so it could also be an X problem. I think it's best to leave the core files for what they are at the moment and let us concentrate on the problems we can solve:) Regards, -- Andre. |
|
From: Olivier C. <oli...@fr...> - 2001-02-20 23:19:43
|
Andre Goeree wrote: > > On Tue, Feb 20, 2001 at 09:25:10AM +0100, Olivier Chapuis wrote: > > > > So, here the errors is not caused by a fifo problem but by an > > error in the perl script fvwm-themes-menuapp which is, > > unfortunately, not very good (it should be rewrote ...). Any way, > > do you have this error when you start the Menu Editor or when > > using it? If it is when you use it can you reproduce this error? > > Finally, do the Theme Center GUI and the Configuration Center > > work? > > Also, if an error of the above type happen now (after my last cvs > > commit) more information on the error will be given to STDERR. > > > > I did some more extensive/structured testing. You will find a report > attached to this message. I can confirm that the creation of fifo's is > not a problem. > Thanks for the report. About, The FvwmScript scripts (Theme and Config Center and the Menu editor) it seems that the perl command "kill" does not work on your bsd machine (or is not used in the good way). Andre, can you try the following. Open an application, say an xterm, see which is the PID of this app. Say that it is pidnum. Then, try perl -e 'print "OK\n" if kill 0 => pidnum' this should print OK. perl -e 'kill 9 => pidnum' this should kill your app. About the problems that cause core, it seems to me that these problems are FVWM problems. What version of FVWM do you use? I strongly encourage you to use 2.3.28 and 2.3.29 when this version will be out (this version will be very close from 2.4). Thanks, Olivier |
|
From: Andre G. <abg...@uw...> - 2001-02-20 13:37:18
|
On Tue, Feb 20, 2001 at 09:25:10AM +0100, Olivier Chapuis wrote: > > So, here the errors is not caused by a fifo problem but by an > error in the perl script fvwm-themes-menuapp which is, > unfortunately, not very good (it should be rewrote ...). Any way, > do you have this error when you start the Menu Editor or when > using it? If it is when you use it can you reproduce this error? > Finally, do the Theme Center GUI and the Configuration Center > work? > Also, if an error of the above type happen now (after my last cvs > commit) more information on the error will be given to STDERR. > I did some more extensive/structured testing. You will find a report attached to this message. I can confirm that the creation of fifo's is not a problem. Regards, --Andre. |
|
From: Olivier C. <oli...@fr...> - 2001-02-20 08:26:59
|
Andre Goeree wrote: > > On Mon, Feb 19, 2001 at 07:50:13PM +0100, Olivier Chapuis wrote: > > > > Hello, > > Sorry to come only now in the discussion. I am happy that > > now every thing work and also that you can, Andre, test > > fvwm-themes on a BSD machine. > > > > Hello Olivier, > > Happy to do some testing:-) > Unfortunately my troubles are not over as i hoped:-\. > [skip Form problems] > What i still don't understand is what happens with the fifo(s). > I still get these kind of errors: > > fvwm-themes-menuapp: internal error 1, kill FvwmScript-Menus This means that an error happen in fvwm-themes-menuapp and this script die. Then, in this very bad case that "should never happen", the FvwmScript "Menu Editor (Personal)" is not more usable so it is killed by fvwm-themes-menuapp after the fatal error (that should never happen ...). Then, the next messages are normal because fvwm-themes-com do not know that menuapp and FvwmScript-Menus die and try to finish the communication between these two programs (see the fvwm-themes-com man page and fvwm-themes-menuapp man page if you want to know more about the "com technology"). > Debug: myMakeFifo creating: .tmp-com-out-menuapp-82421 > com: No lock Fifo .tmp-com-lock-menuapp-82421 for menuapp-82421 communication > Debug: myMakeFifo creating: .tmp-com-out-menuapp-82421 > com: No lock Fifo .tmp-com-lock-menuapp-82421 for menuapp-82421 communication > > Note that i put an extra print in the script indicating that > the function is run. I can see the file .tmp-com-out-* but none > of the other two files .tmp-com-[lock|in] as the error indicates. > I also tried the -m option of mkfifo(1) to see if that made any > difference, no dice.. > So, here the errors is not caused by a fifo problem but by an error in the perl script fvwm-themes-menuapp which is, unfortunately, not very good (it should be rewrote ...). Any way, do you have this error when you start the Menu Editor or when using it? If it is when you use it can you reproduce this error? Finally, do the Theme Center GUI and the Configuration Center work? Also, if an error of the above type happen now (after my last cvs commit) more information on the error will be given to STDERR. Regards, Olivier |
|
From: Mikhael G. <mi...@ho...> - 2001-02-20 01:26:22
|
On 20 Feb 2001 00:33:21 +0100, Andre Goeree wrote: > > Unfortunately my troubles are not over as i hoped:-\. > But i have done a little research and i think i've come > a little closer to the source of the problem. It seems > to be the config files, especially .FvwmForm, that cause > the error and occasional core dumps. > If i use -themes and logout/switch to fvwm the "Form Configuration" > shows up all black. > When i rm -fr the .fvwm directory and set the default > "Form Configuration" from within fvwm and then switch to > themes, some forms don't work or make FvwmForm dump core. > Note that setup95 doesn't create a default .FvwmForm and that > i'm not to sure this time;) "Form Defaults" form creates this .FvwmForm file. It is a good idea never to have this file, since it overrides colors defined by fvwm-themes, which allocates its own colors for FvwmForm's. The correct way to define colors which are good for fvwm-themes is to specify colorsets 36 and 34. But then if you run FVWM without fvwm-themes you will get black on black, since these colorsets are not defined. You may try to reproduce the problem. If you have a core dump file, execute "where" at the (gdb) prompt and post the output. Also tell us what you use (themes or not, which themes). Also post your ~/.fvwm/.FvwmForm file. [I leave com problems to Olivier] > /notes > Although i don't think permissions are a problem here, i believe > using "mkfifo -m" is a good standard to use, here's why: > > (from the man page) > If the -m option is not specified, fifos are created with mode 0666 > modified by the umask(2) of the calling process. The mkfifo command > requires write permission in the parent directory. > > By using the -m [u=rw] option, you guarantee that the fifo is created > with the right permissions. > /notes This is one of those cases when I dislike programs trying to be smarter than users. We should fully respect user's umask, not impose arbitrarily chosen file permissions. Suppose we use 0600 and the script is killed at the middle, now other users from the same group can't delete/change this file despite that umask 2 allows this. Or instead we use 0660, now other users from the same group can change this file, but it is not allowed this time by umask 22. So the current code, which respects umask, is good. Regards, Mikhael. |
|
From: Andre G. <abg...@uw...> - 2001-02-19 23:31:02
|
On Mon, Feb 19, 2001 at 07:50:13PM +0100, Olivier Chapuis wrote: > Andre Goeree wrote: > > Hmm, all my troubles with fvwm-themes suddenly disappeared when i > > started with a fresh (empty) ~/.fvwm (now, why didn't i think of > > that in the first place?). > > > > Hello, > Sorry to come only now in the discussion. I am happy that > now every thing work and also that you can, Andre, test > fvwm-themes on a BSD machine. > Hello Olivier, Happy to do some testing:-) Unfortunately my troubles are not over as i hoped:-\. But i have done a little research and i think i've come a little closer to the source of the problem. It seems to be the config files, especially .FvwmForm, that cause the error and occasional core dumps. If i use -themes and logout/switch to fvwm the "Form Configuration" shows up all black. When i rm -fr the .fvwm directory and set the default "Form Configuration" from within fvwm and then switch to themes, some forms don't work or make FvwmForm dump core. Note that setup95 doesn't create a default .FvwmForm and that i'm not to sure this time;) > I do not see how setup95 can interact with fvwm-themes > (but I do not think a lot on this). > Also, it is possible that the problem came from fvwm-themes > itself: a config file from an old version may be the cause > of some problems ... > That's also a possibility. What i still don't understand is what happens with the fifo(s). I still get these kind of errors: fvwm-themes-menuapp: internal error 1, kill FvwmScript-Menus Debug: myMakeFifo creating: .tmp-com-out-menuapp-82421 com: No lock Fifo .tmp-com-lock-menuapp-82421 for menuapp-82421 communication Debug: myMakeFifo creating: .tmp-com-out-menuapp-82421 com: No lock Fifo .tmp-com-lock-menuapp-82421 for menuapp-82421 communication Note that i put an extra print in the script indicating that the function is run. I can see the file .tmp-com-out-* but none of the other two files .tmp-com-[lock|in] as the error indicates. I also tried the -m option of mkfifo(1) to see if that made any difference, no dice.. /notes Although i don't think permissions are a problem here, i believe using "mkfifo -m" is a good standard to use, here's why: (from the man page) If the -m option is not specified, fifos are created with mode 0666 modified by the umask(2) of the calling process. The mkfifo command requires write permission in the parent directory. By using the -m [u=rw] option, you guarantee that the fifo is created with the right permissions. /notes Regards, -- Andre. |
6 messages has been excluded from this view by a project administrator.
