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-01-18 22:54:14
|
Mikhael Goikhman wrote:
>
> Theoretically a lot of improvements may be done to icons included in
> wm-icons, like borrowing (or drawing!) new icon sets, adding new icons
> and replacing existing ones. But I am a realist. It seems that artists
> needed for working on icons are not in any near place. So I would
> concentrate on the following tasks:
>
> (1) Which icon names to have. Currently there are 60 icon names.
> All icon sets include 60 icons, some (missing) are symlinked to others
> in the same icon set, for example netscape icon may be symlinked to www
> icon, which in its turn may be symlinked to network icon. The names are:
>
> calculator cd-player chat choice-no
> choice-yes clock debugger desktop
> disk-cd disk-floppy disk display
> editor empty folder folders
> font game-cards game-chess game
> ghostview help home image-viewer
> information keyboard mail monitor
> mouse music netscape network
> shell sound terminal todo
> unknown utility viewer window-close
> window-delete window-destroy window-iconify window-identify
> window-lower window-maximize window-move window-raise
> window-resize window-shade window-stick window
> wm-lock wm-quit wm-refresh wm-restart
> word-processor www xterm xv
>
> There are total of 16*60, i.e. 960 xpm files. We should obviousely
> increase this number. :) Actually we may remove some icon sets, but
> the number of icons in each icon set probably will be greater than 60.
>
> Do you have any preferences. Is there icon (category), which you miss
> and can't leave without it? Speak then.
>
Hello,
This mail concern which icons we should have. I think that one of the main
idea of wm-icons is to have icons which represent categories and not icons
for everything (the second main idea is to provide different set of icons
for themability). Of course there are a few exceptions: the window-* icons
for example, but these icons are just sub categories and we should have it.
Really I think that the categories way is the good way. But I like to have
the icons (in fact I "never" use icons but I use mini-icons) associated
to applications (e.g., "the" gimp icon with gimp, the xemacs icons with
xemacs, ...). There are no contradictions here, the solution is to add
to wm-icons a few "extensions" icons sets for applications. Says
16x16-general-apps, 32x32-general-apps and 48x48-general-apps and symlink apps-mini, apps-menu, apps-norm.
So here we lost the themability (and of course categories), but for this
kind of icons this is normal. In practices these new sets of icons will be
optional and do not contain (transformed) icons from kde and gnome which will
be another kind of extension to wm-icons (in configuration files generated
by wm-icons/fvwm-themes).
In abstract IMHO the wm-icons base set (i.e., the current icons set) should
have icons for all imaginable categories but no applications specific icons
which will be in these extension icons set. Of course we can have a few
exceptions, at the present time: netscape, xv, ghostview and in your plan
gimp and in a certain sense gnu (emacs). So it may be a good idea to have
a few applications in these base icons set for the most famous
X applications and this is not really a problem that one set does not
have it because then we use a symlink to the categories icons.
So let go back to our ship: the base icons sets.
> I thought about the following changes to the icon list. The first number
> is current priority (in percents), it may be changed. Probably we may
> do only changes marked greater than 50%. Please feel free to correct this
> list, it is hard for me to decide myself. All changes require a lot of
> work on modifying the existing icons set to match the new list, but this
> is not important for now. Please understand that simply a request for, say,
> gimp icon is not enough, there should be at least several existing icons
> good for different icon sets (in different sizes).
>
> * add/rename/remove these icons:
> 90 add gnome
> 90 add kde
> 90 add gnu
> 90 rename game-chess game-board
> 80 add terminal-remote
> 80 add terminal-special
> 70 add file
> 70 rename folders file-manager
> 70 add folder-open
> 60 add game-action
> 60 add game-logic
> 60 add game-strategy
> 60 add amusements
> 60 add image-editor (image-processor?)
> 50 add windows (many window-s)
> 50 add modules
> 50 add configuration
> 40 add fvwm
> 40 remove shell
> 40 remove xterm
> 40 rename terminal term
> 30 add colors
> 20 add gimp
>
Basically agree with this and with the fact that we have to add those
with a priority >= 50. fvwm and gimp may go to the apps icons sets
and for "personal" reason I will put colors to priority 50 :o)
Now I think that we need to add a *lot* of names. First, if I look at
the fvwm-themes root menus we needs:
50 programs (can be a symlink to utility)
60 system (can be a symlink to monitor)
90 configuration (in your list)
90 modules (in your lists)
50 themes
Now I go further in the menus. First if I look to our "root" programs
menus (and one I've planed in a previous messages) as well as to the
kde "root" programs menus we need:
50 applications (can be a symlink to utility)
50 office (can be a symlink to desktop but seems <> for me)
50 text (can be a symlink to informations or viewer)
50 science (can be symlink to calculator)
50 multimedia (can be a symlink to sound but <>)
An interesting system is the debian menu package (used by Mandrake).
Here there are lot of sub categories but the only top category
without an obvious wm-icons (office is their to) is
40 session (can be a symlink to desktop or wm-restart)
50 office (again)
50 multimedia
Now if I go to the debian sub categories we "need":
Under config:
?? hardware
?? packaging
70 printer (no obvious symlink)
?? boot
Under applications:
?? development
50 science (again)
?? emulators
?? archiving (can be a symlink to file)
80 monitoring (can be a symlink to monitor and a better
name is system-stat)
?? publishing
50 text (again)
Under Networks:
50 download (can be symlink to file)
60 news (can be a symlink to chat)
60 connection (I.e., remote access, isp, ..., need a better name,
easy symlink)
Under Games:
40 sports
60 some in your list (in fact I take in account your list)
?? games-puzzles (can be a symlink games-logic)
?? games-aventure (can be a symlink games-action or strategy)
Under Multimedia:
80 video
There are also sub sub categories under applications. These suggest to
me:
50 hex
50 science-graph (can be a symlink to science)
50 science-astronomy (ditto)
50 science-nature (ditto)
?? compression
?? backup
So that's it for "programs" icons. I think that it will be go that
wm-icons have a support for the (powerful and very good) debian
system menu). What system is used with RedHat and Suse? I think
that more or less supporting Debian/RedHat et al./Suse will
be good.
Let us continue the fvwm-themes menu:
50 theme (different from themes)
?? component
30 cursor
?? animation (symlink to window-iconify)
?? may be one or two configuration-*
90 x
?? background (symlink to colors)
60 icons o:)
?? help-man (symlink to help)
?? pager
?? panel/buttons
?? winlist
?? applet
?? wm (can be a symlink to windows)
Others:
50 penguin
50 start
60 ball (component can be a symlink to this)
?? os (can be a symlink to penguin :o)
?? cde (better into apps icons set)
?? distributions
Renaming
?? wm-lock, wm-restart, wm-quit, wm-refresh to lock, restart,
quit, refresh (more generic)
That's all :o). Of course the 50% have not the same meanings that
for your reasonable list. Moreover, I am new with wm-icons. But,
I will say that for me the icons with priority > 50 should be added.
Also, those with a priority of 50 with an obvious symlink can also
be added. For the ?? one, its depends of the future of the discussions
This gives:
90 x
80 video
80 monitoring or better system-stat (can be a symlink to monitor)
70 printer (no obvious symlink)
60 ball
60 icons
60 system (can be a symlink to monitor)
60 news (can be a symlink to chat)
60 connection (I.e., remote access, isp, ..., need a better name,
easy symlink)
50 + an easy symlink:
50 programs (can be a symlink to utility)
50 applications (can be a symlink to utility)
50 office (can be a symlink to desktop but seems <> for me)
50 text (can be a symlink to information's or viewer)
50 science (can be symlink to calculator)
50 multimedia (can be a symlink to sound but <>)
50 download (can be symlink to file)
50 hex (can be a symlink to information or text)
50 science-graph (can be a symlink to science)
50 science-astronomy (ditto)
50 science-nature (ditto)
No obvious symlink and 50%
50 themes
50 theme (different from themes)
50 penguin
50 start
Others (it will be good to do a new rating):
40 session (can be a symlink to desktop or wm-restart)
?? hardware
?? packaging
?? boot
?? development (can be a symlink to bug :o)
?? emulators
?? archiving (can be a symlink to file)
?? publishing (can be a symlink)
?? games-puzzles (can be a symlink games-logic)
?? games-aventure (can be a symlink games-action or strategy)
?? compression (file or ...)
?? backup (file or folders)
?? component (ball)
30 cursor (icons)
?? animation (symlink to window-iconify)
?? may be one or two configuration-*
?? background (symlink to colors)
?? help-man (symlink to help)
?? pager
?? panel/buttons
?? winlist
?? applet
?? wm (can be a symlink to windows)
?? os (can be a symlink to penguin :o)
?? cde (better into apps icons set)
?? distributions
Of course I can provides and also do some icons (especially for
kde and general icons set). Finally we can try to do a gnome icons
set.
Olivier
|
|
From: Mikhael G. <mi...@ho...> - 2001-01-16 02:55:34
|
Theoretically a lot of improvements may be done to icons included in
wm-icons, like borrowing (or drawing!) new icon sets, adding new icons
and replacing existing ones. But I am a realist. It seems that artists
needed for working on icons are not in any near place. So I would
concentrate on the following tasks:
(1) Which icon names to have. Currently there are 60 icon names.
All icon sets include 60 icons, some (missing) are symlinked to others
in the same icon set, for example netscape icon may be symlinked to www
icon, which in its turn may be symlinked to network icon. The names are:
calculator cd-player chat choice-no
choice-yes clock debugger desktop
disk-cd disk-floppy disk display
editor empty folder folders
font game-cards game-chess game
ghostview help home image-viewer
information keyboard mail monitor
mouse music netscape network
shell sound terminal todo
unknown utility viewer window-close
window-delete window-destroy window-iconify window-identify
window-lower window-maximize window-move window-raise
window-resize window-shade window-stick window
wm-lock wm-quit wm-refresh wm-restart
word-processor www xterm xv
There are total of 16*60, i.e. 960 xpm files. We should obviousely
increase this number. :) Actually we may remove some icon sets, but
the number of icons in each icon set probably will be greater than 60.
Do you have any preferences. Is there icon (category), which you miss
and can't leave without it? Speak then.
I thought about the following changes to the icon list. The first number
is current priority (in percents), it may be changed. Probably we may
do only changes marked greater than 50%. Please feel free to correct this
list, it is hard for me to decide myself. All changes require a lot of
work on modifying the existing icons set to match the new list, but this
is not important for now. Please understand that simply a request for, say,
gimp icon is not enough, there should be at least several existing icons
good for different icon sets (in different sizes).
* add/rename/remove these icons:
90 add gnome
90 add kde
90 add gnu
90 rename game-chess game-board
80 add terminal-remote
80 add terminal-special
70 add file
70 rename folders file-manager
70 add folder-open
60 add game-action
60 add game-logic
60 add game-strategy
60 add amusements
60 add image-editor (image-processor?)
50 add windows (many window-s)
50 add modules
50 add configuration
40 add fvwm
40 remove shell
40 remove xterm
40 rename terminal term
30 add colors
20 add gimp
(2) Currently icons are bound to applications using either class or
resource names, and in some minor cases maybe a window name (see
the file themes/default/settings/iconstyles/style-icon-miniicon in
fvwm-themes or the file devel/conf/style-icons.cfg in wm-icons).
Olivier suggested a way to define such binding (not only for wm-icons,
but also for the native kde and gnome icons, converted to xpm). I still
think about this idea. It would be nice to find an easy, but flexible
way to define a database of application resource names.
(3) A way to auto-generate icon sets. Say, get an existing (transparent)
icon set, get a non transparent background patern and generate a new
icon set from this. Or maybe shrink down/resize an existing icon set.
Would be also nice to do this somehow on the fly.
There are more, but let stop on these tasks first.
If you (all) are interesting to work on icons, please speak, there are
different independent tasks to choose from. Some are hard - creating new
icon sets, some easy - suggesting new icon names or finding replacements
for icons which annoy you. There is also a place for scripting.
Regards,
Mikhael.
|
|
From: Mikhael G. <mi...@ho...> - 2001-01-16 01:57:14
|
I have finally finished rearranging wm-icons, including removal of all symlinks, and placed it in cvs at sourceforge.net. The cvs info is at: https://sourceforge.net/cvs/?group_id=3485 Generally speaking, working on wm-icons at sourceforge.net is the same as on fvwm-themes, just replacing fvwm-themes string anywhere in links and shell commands. I have added Olivier to the project admins. I have set the same 'make rpm-dist' configuration for wm-icons as for fvwm and fvwm-themes. Currently all 15 icon sets are placed in one rpm. In case you don't know about wm-icons (fvwm-themes includes 2 of its 15 icon sets), the info about it can be found at the home page: http://wm-icons.sourceforge.net/ I will send my plans and thoughts about wm-icons to this list shortly. Regards, Mikhael. |
|
From: RICO <eri...@ca...> - 2001-01-12 17:46:52
|
|
From: Mikhael G. <mi...@ho...> - 2001-01-02 00:03:09
|
On 02 Jan 2001 00:16:44 +1030, Alex Wallis wrote: > > I've been getting these errors for awhile now. > > [FVWM][Read]: <<ERROR>> file > '/opt/fvwm/themes/default/settings/kde/disabled' not found in > /home/awol/.fvwm or /opt/fvwm This is a strange error. Can you try 'cvs update -dA' and then reinstall. If this error is still here, please send the last (Read) lines of your ~/.fvwm/themes-rc-2. > syntax error at /opt/fvwm/bin/fvwm-menu-desktop line 429, near "require > v5.6" > Execution of /opt/fvwm/bin/fvwm-menu-desktop aborted due to compilation > errors. > > Consequently I do not get my kde menus! :( > > Does this mean perl needs to be v5.6? No, this just was an incompatible check for 5.6. Fixed. Regards, Mikhael. |
|
From: Alex W. <aw...@do...> - 2001-01-01 13:48:02
|
I've been getting these errors for awhile now. [FVWM][Read]: <<ERROR>> file '/opt/fvwm/themes/default/settings/kde/disabled' not found in /home/awol/.fvwm or /opt/fvwm syntax error at /opt/fvwm/bin/fvwm-menu-desktop line 429, near "require v5.6" Execution of /opt/fvwm/bin/fvwm-menu-desktop aborted due to compilation errors. Consequently I do not get my kde menus! :( Does this mean perl needs to be v5.6? Alex |
|
From: Mikhael G. <mi...@ho...> - 2000-12-31 17:27:39
|
On 30 Dec 2000 19:33:20 +0100, Olivier Chapuis wrote:
>
> If not I've:
> - provides: just to define keys
> - follows/precedes: just order relations (need to be extended to the
> provides keys)
> - requires: order + reload the component that provides if
> the one which requires is reloaded
> - extends: no order but reload the two components if one is reloaded
> - needs: no order but reload the needed component
My definition of "extends" is different.
As I wrote, I really prefer for now instead of changing rules, to hardcode
the reload dependances:
$reloads = {
'bindings' => [ 'settings/stroke', 'globalfeel' ],
...
};
> Moreover I can hard code the extra component dependence, or we can add
> immediate?
I planned to solve this after a New Year.
Regards,
Mikhael.
|
|
From: Olivier C. <oli...@fr...> - 2000-12-30 18:33:14
|
Mikhael Goikhman wrote: > > On 29 Dec 2000 10:48:35 +0100, Olivier Chapuis wrote: > > > > > I think we may suppose that load and reload is the same, i.e. there is no > > > need in individual 'read-command' or 'start-stop' (which I don't quite > > > understand anyway without example). > > > > Examples: 1 - says that we have to reload colors, then we need to reload > > only a very small part of modules: we need to restart the modules which > > contains certain swallowed applications. So well implemented modules > > component may contains a ColorsModules start-stop function which restart > > the desired modules and the cfg may contains: > > > > requires+name=colors-modules > > requires.order=1 > > requires.needs=1 > > requires.exist=1 > > requires.read-command=Nop > > requires.start-stop=ColorsModules > > > > 2 - say that we have to reload globalfeel which contains the default styles, > > then again we have to reload a small part of modules: the styles of the > > modules which are in main:styles. > > > > Most of the examples are with modules and one can probably found examples > > with settings components. This is normal, modules components are complex: > > each one almost define a different window manager and represent a themes > > on its own. > > I have mixed feelings here (as usual). It would be nice to have such > optimizations, but they are not easy to implement/specify for potential > theme creators. Having such granularity (i.e. reload != load) also means > we can't break MR task in two independant parts, as follows: > > > > 1) Evaluate a set of components needed for MR. > > > 2) Implement MR using themes-rc-3 or whatever. > > So, I have no problems if we don't do these optimizations at all. Waiting > for a full component reload is probably better than having incomplete one. > I am really for this fine granularity because we will see the modules restart too often in my opinion (and fvwm-themes must be more powerful as we can even if this gives difficulty to theme creators). But, ok let put this subject for the future ... So I've released 1) and 2), but there is a problem: I really need to extend the dependency rule. Are you ok for the 2 dependency rules with many parameters (order, needs, existence)? It will allow for example to come back to te previous subject. If not I've: - provides: just to define keys - follows/precedes: just order relations (need to be extended to the provides keys) - requires: order + reload the component that provides if the one which requires is reloaded - extends: no order but reload the two components if one is reloaded - needs: no order but reload the needed component That's it? If yes we may suppress requires since it can be simulated by follows+needs (and extends since it can be simulated by 2 needs)? Moreover I can hard code the extra component dependence, or we can add immediate? Regards, Olivier |
|
From: Mikhael G. <mi...@ho...> - 2000-12-30 02:47:57
|
On 29 Dec 2000 10:48:18 +0100, Olivier Chapuis wrote: > > "an extra component must share the same dependency rule > that its associated component" Yes, of course. We need a new meta-rule for this, or hardcode a special role of extra components. > > > 2. It will be great to have component of the form > > > theme-component-extra loaded if selected and if > > > component@theme is used. > > So an example: typically a user can like modules@foo and modules@xyz > ((s)he use foo or xyz accordingly to a given reason that I do not know), > however (s)he want to modify a bit both component in an incompatible way, > so this user will want to have modules-foo-extra and modules-xyz-extra. Seems then you want to have simply files to be auto-read, Not components, because these files have no behaviours of components (they can't be loaded/dropped/locked, can't provide or require anything, although they teoretically can have options/variants). I am not against this, but I would try not to add complexity. If there are 42 components, it should scan 42 files (most/all of which does not exist), this may be slow, say, on NFS (I only guess). On the other hand to add an option means to add interface to set/unset it, place to store (i.e. complexity). I can't find now a good way to add this additional Read. > > > Also it will be great to have extra component for the settings. Doing this for every sub component will slow fvwm-themes-config. At least on slow filesystems. If you see a good solution, do it. Regards, Mikhael. |
|
From: Mikhael G. <mi...@ho...> - 2000-12-30 02:47:57
|
On 29 Dec 2000 10:48:35 +0100, Olivier Chapuis wrote: > > > I think we may suppose that load and reload is the same, i.e. there is no > > need in individual 'read-command' or 'start-stop' (which I don't quite > > understand anyway without example). > > Examples: 1 - says that we have to reload colors, then we need to reload > only a very small part of modules: we need to restart the modules which > contains certain swallowed applications. So well implemented modules > component may contains a ColorsModules start-stop function which restart > the desired modules and the cfg may contains: > > requires+name=colors-modules > requires.order=1 > requires.needs=1 > requires.exist=1 > requires.read-command=Nop > requires.start-stop=ColorsModules > > 2 - say that we have to reload globalfeel which contains the default styles, > then again we have to reload a small part of modules: the styles of the > modules which are in main:styles. > > Most of the examples are with modules and one can probably found examples > with settings components. This is normal, modules components are complex: > each one almost define a different window manager and represent a themes > on its own. I have mixed feelings here (as usual). It would be nice to have such optimizations, but they are not easy to implement/specify for potential theme creators. Having such granularity (i.e. reload != load) also means we can't break MR task in two independant parts, as follows: > > 1) Evaluate a set of components needed for MR. > > 2) Implement MR using themes-rc-3 or whatever. So, I have no problems if we don't do these optimizations at all. Waiting for a full component reload is probably better than having incomplete one. > I am ready to start *very smoothly* the MR implementation (using #ccds > comments). Ok. Regards, Mikhael. |
|
From: Olivier C. <oli...@fr...> - 2000-12-29 09:47:56
|
Mikhael Goikhman wrote: > > On 24 Dec 2000 12:41:12 +0100, Olivier Chapuis wrote: > > > > I think we must work on CCDS now. Mikhael do you have any plan > > about this? > > My plan is to work on wm-icons first. :) > Both fvwm-menu scripts and fvwm-themes depend on it. > We may work on the minimal reload (MR) concurrently too. > Ok, I let you start a thread on wm-icons :o) > > 3. At the present time we have "requires/provides" and "follows" > > dependency rules. These rules allow to build the "all" config > > in the good order. We want to do more: (a) reload only the > > needed components during theme switch (b) check dependence > > consistency and either automatically load/drop some components > > or generate an error messages if some inconsistency happen. > > > > I think that the requires/provides rule are goods and that we > > may want to only have this rule (follows is just a kind of > > alias). However, I think that there are not enough precise: > > if a component A provides foo and B requires foo, there > > are a lot of different possible reasons for this dependence: > > > > - (order): A must be loaded before B (order=1) or B must be > > loaded before (order=-1, a priorie this never > > happen but ....). We can have also order=+/-2 for > > immediately after/before. > > > > - (existence): So that B can be used A must be present > > (exist=1) > > > > - (needs): if B have to be reload, A have to be reloaded too > > (needs=1) or if A have to be loaded B have to be > > reloaded (needs=2), or both (needs=3). > > > > - maybe others ...? > > Originally I though about 'extends' (which is like both 'requires' and > 'provides'); 'provides-extends' (which becomes 'provides' if there is no > other 'provides', or 'extends' otherwise; and 'uses' (requires existence, > but order is not important unlike 'requires' and 'extends', it also does > not participate in MR). > > Probably there are more cases, but I can't think about any. > > > Of course we may have to found better name than order, needs and exists. > > Also some hints can be given for partial load reload of a component > > > > So in cfg files we have > > > > provides+name=foo # maybe id in the place of name? > > provides.read-command=read blabla # default is the component read command > > provides.start-stop=Xyz # default to the component start-stop > > > > .... > > > > requires+name=foo > > requires.order=a # default to nothing or 1? > > requires.exist=b # default to nothing (0) > > requires.needs=c # default to nothing > > requires.read-command=read pouf # default is the component read command > > requires.start-stop=Zyx # default to the component start-stop > > I am not sure whether 2 dependancy rules with many parameters is better > than several dependancy rules without parameters. > Seems more natural for me: there is a dependency: provides/requires; but why we have such a dependency? The parameters give the reason and even more hints. Assume for a moment that we need all the previous dependency and that we use rules without parameters. Then, we need 54 requires rules and we have no special reload hints. Of course all the cases will not be needed but we are ready for a lot of situation that may arise (and which will arise when implementing MR). > I think we may suppose that load and reload is the same, i.e. there is no > need in individual 'read-command' or 'start-stop' (which I don't quite > understand anyway without example). > Examples: 1 - says that we have to reload colors, then we need to reload only a very small part of modules: we need to restart the modules which contains certain swallowed applications. So well implemented modules component may contains a ColorsModules start-stop function which restart the desired modules and the cfg may contains: requires+name=colors-modules requires.order=1 requires.needs=1 requires.exist=1 requires.read-command=Nop requires.start-stop=ColorsModules 2 - say that we have to reload globalfeel which contains the default styles, then again we have to reload a small part of modules: the styles of the modules which are in main:styles. Most of the examples are with modules and one can probably found examples with settings components. This is normal, modules components are complex: each one almost define a different window manager and represent a themes on its own. > > 4. Implementation. The order stuff is already perfectly implemented. I'm > > really concerned about "minimal reloading". > > [closure definition skipped] > > I think we should only work with directional graphs, it is in fact not any > harder than non-directional ones. > > I see this similarly to you. There are 2 independant parts. > > 1) Evaluate a set of components needed for MR. > 2) Implement MR using themes-rc-3 or whatever. > > We may temporarily implement (1) by hardcoding a hash of C => MR(C), > and than just conjunctArrays() of components. > > After implementing (2) we may return to (1), implementing this using CCDS. > Then we will see better which rules are needed for MR. > > > we have to rebuild > > the themes-rc-2 file and need to update the theme management > > menu but we surely not have to read themes-rc-2. A simple solution > > is to add themes-menu. There is also a problem with the stop function. > > Finally, I think we have to add a global variable to ft-config, > > ENABLE_CCDS, set to 0 by default and the "new" code will apply if it > > is set 1. > > I don't think we need menus-themes@, but we will see. > > It would be better to turn MR on and off dynamically using something like > --set-minimal-reload and storing this boolean in _core@current component. > I am agree with all the previous. I like the menus-themes@ because of the GUI, some GUI have hard coded MR implemented (so that ConfigCenter is really usable for example) and so change they done cannot be reflected immediatly in the themes management menu. If we implement MR this menus-themes@ will be probably not needed but this may depends on the implementation. we will see ... I am ready to start *very smoothly* the MR implementation (using #ccds comments). Olivier |
|
From: Olivier C. <oli...@fr...> - 2000-12-29 09:47:39
|
Mikhael Goikhman wrote:
>
> > I think a little bit about this. Here a few reflections:
> >
> > 1. I think that the *-extra components need to have a special
> > dependence rule: they should be loaded *immediatly* after its
> > corresponding (*) component (and we may want to add an cfg command
> > to force the extra component to be loaded just before its
> > corresponding component).
>
> Maybe. But if we implement extends as it was intended, this may be enough.
> Extra components do not really should go immediately after. Maybe it looks
> better for human when they go together, but not really needed.
>
Take as an example the styles component (or think with a component with
a lot of dependency rules). There is a lot of dependency rules for this
component. The style-extra component should a priori share the same
rules since this component may contains the same type of configuration
commands as the style component. Note that at the present time the
dependency rule for this extra component is done so that the modules
component is loaded after style-extra (provide+=special-styles in
style-extra and requires+=special-style in modules, before I change this
a few days ago, a similar trick was used that you implement). With no such
a special rule (this is the only extra component with a provieds/requires
cfg command) the style/modules order will be: styles,modules,extra-styles.
All this means that:
"an extra component must share the same dependency rule
that its associated component"
(which is a meta-rule :o). So I think we should really load an extra
component together its associated component. Either by
a. Adding dependency rule in the *-extra cfg entries
b. Automatically transfer the dependency rule of a component
to its extra component
c. loading the extra components immediately after their components.
(a) is not good for a lot of reason. (b) and (c) seems ok for me
but (c) seems simpler (and probably "faster").
> > 2. It will be great to have component of the form
> > theme-component-extra loaded if selected and if
> > component@theme is used.
>
> Do you mean load (first choosing) or minimal reload? Please give example.
>
So an example: typically a user can like modules@foo and modules@xyz
((s)he use foo or xyz accordingly to a given reason that I do not know),
however (s)he want to modify a bit both component in an incompatible way,
so this user will want to have modules-foo-extra and modules-xyz-extra.
> > Also it will be great to have extra component for the settings.
>
> For every sub-component? Teoretically this may help. but practically it
> would be better to add a new setting or move this subcomponent outside of
> settings@ if it needs more customization.
>
About new setting I'm afraid that we have to add an infinite number of
new settings. Also we can move a lot of settings stuff outside it,
since we have drop. However, I like a lot the settings idea and
not a lot dropping (which is a useful thing for sure). The component
outside settings are the natural components (but the extra) and for
a *normal* use no such component have to be dropped. On the other
hands the settings component are "option" it is natural to "drop"
such a component for a number of reasons. We can move all the
settings stuff outside it but I think that this will confuse a
lot the users. FVWM Themes is complicated, I think that settings
help the users to understand it even if the difference between a
settings sub-component and normal component is only psychological.
Olivier
|
|
From: Mikhael G. <mi...@ho...> - 2000-12-29 03:03:35
|
On 24 Dec 2000 12:41:12 +0100, Olivier Chapuis wrote: > > I think we must work on CCDS now. Mikhael do you have any plan > about this? My plan is to work on wm-icons first. :) Both fvwm-menu scripts and fvwm-themes depend on it. We may work on the minimal reload (MR) concurrently too. > I think a little bit about this. Here a few reflections: > > 1. I think that the *-extra components need to have a special > dependence rule: they should be loaded *immediatly* after its > corresponding (*) component (and we may want to add an cfg command > to force the extra component to be loaded just before its > corresponding component). Maybe. But if we implement extends as it was intended, this may be enough. Extra components do not really should go immediately after. Maybe it looks better for human when they go together, but not really needed. > 2. It will be great to have component of the form > theme-component-extra loaded if selected and if > component@theme is used. Do you mean load (first choosing) or minimal reload? Please give example. > Also it will be great to have extra component for the settings. For every sub-component? Teoretically this may help. but practically it would be better to add a new setting or move this subcomponent outside of settings@ if it needs more customization. > 3. At the present time we have "requires/provides" and "follows" > dependency rules. These rules allow to build the "all" config > in the good order. We want to do more: (a) reload only the > needed components during theme switch (b) check dependence > consistency and either automatically load/drop some components > or generate an error messages if some inconsistency happen. > > I think that the requires/provides rule are goods and that we > may want to only have this rule (follows is just a kind of > alias). However, I think that there are not enough precise: > if a component A provides foo and B requires foo, there > are a lot of different possible reasons for this dependence: > > - (order): A must be loaded before B (order=1) or B must be > loaded before (order=-1, a priorie this never > happen but ....). We can have also order=+/-2 for > immediately after/before. > > - (existence): So that B can be used A must be present > (exist=1) > > - (needs): if B have to be reload, A have to be reloaded too > (needs=1) or if A have to be loaded B have to be > reloaded (needs=2), or both (needs=3). > > - maybe others ...? Originally I though about 'extends' (which is like both 'requires' and 'provides'); 'provides-extends' (which becomes 'provides' if there is no other 'provides', or 'extends' otherwise; and 'uses' (requires existence, but order is not important unlike 'requires' and 'extends', it also does not participate in MR). Probably there are more cases, but I can't think about any. > Of course we may have to found better name than order, needs and exists. > Also some hints can be given for partial load reload of a component > > So in cfg files we have > > provides+name=foo # maybe id in the place of name? > provides.read-command=read blabla # default is the component read command > provides.start-stop=Xyz # default to the component start-stop > > .... > > requires+name=foo > requires.order=a # default to nothing or 1? > requires.exist=b # default to nothing (0) > requires.needs=c # default to nothing > requires.read-command=read pouf # default is the component read command > requires.start-stop=Zyx # default to the component start-stop I am not sure whether 2 dependancy rules with many parameters is better than several dependancy rules without parameters. I think we may suppose that load and reload is the same, i.e. there is no need in individual 'read-command' or 'start-stop' (which I don't quite understand anyway without example). > 4. Implementation. The order stuff is already perfectly implemented. I'm > really concerned about "minimal reloading". [closure definition skipped] I think we should only work with directional graphs, it is in fact not any harder than non-directional ones. I see this similarly to you. There are 2 independant parts. 1) Evaluate a set of components needed for MR. 2) Implement MR using themes-rc-3 or whatever. We may temporarily implement (1) by hardcoding a hash of C => MR(C), and than just conjunctArrays() of components. After implementing (2) we may return to (1), implementing this using CCDS. Then we will see better which rules are needed for MR. > we have to rebuild > the themes-rc-2 file and need to update the theme management > menu but we surely not have to read themes-rc-2. A simple solution > is to add themes-menu. There is also a problem with the stop function. > Finally, I think we have to add a global variable to ft-config, > ENABLE_CCDS, set to 0 by default and the "new" code will apply if it > is set 1. I don't think we need menus-themes@, but we will see. It would be better to turn MR on and off dynamically using something like --set-minimal-reload and storing this boolean in _core@current component. Regards, Mikhael. |
|
From: Mikhael G. <mi...@co...> - 2000-12-25 20:33:43
|
On 24 Dec 2000 07:02:46 +0100, Olivier Chapuis wrote: > > Do you have some objections for having dot files under $FVWM_USERDIR for > the FVWM Themes FvwmScript? If it is a persistent tool configuration, like .FvwmScript-FontSelector, it is ok. But I would prefer to have temporary files in /tmp instead or/and desirably delete them after usage. Anyway, this is not very important for me. At least for now when we don't have many dot files. Regards, Mikhael. |
|
From: Olivier C. <oli...@fr...> - 2000-12-25 00:17:14
|
Hello,
I think we must work on CCDS now. Mikhael do you have any plan
about this?
I think a little bit about this. Here a few reflections:
1. I think that the *-extra components need to have a special
dependence rule: they should be loaded *immediatly* after its
corresponding (*) component (and we may want to add an cfg command
to force the extra component to be loaded just before its
corresponding component).
2. It will be great to have component of the form
theme-component-extra loaded if selected and if
component@theme is used. Also it will be great to have
extra component for the settings.
3. At the present time we have "requires/provides" and "follows"
dependency rules. These rules allow to build the "all" config
in the good order. We want to do more: (a) reload only the
needed components during theme switch (b) check dependence
consistency and either automatically load/drop some components
or generate an error messages if some inconsistency happen.
I think that the requires/provides rule are goods and that we
may want to only have this rule (follows is just a kind of
alias). However, I think that there are not enough precise:
if a component A provides foo and B requires foo, there
are a lot of different possible reasons for this dependence:
- (order): A must be loaded before B (order=1) or B must be
loaded before (order=-1, a priorie this never
happen but ....). We can have also order=+/-2 for
immediately after/before.
- (existence): So that B can be used A must be present
(exist=1)
- (needs): if B have to be reload, A have to be reloaded too
(needs=1) or if A have to be loaded B have to be
reloaded (needs=2), or both (needs=3).
- maybe others ...?
Of course we may have to found better name than order, needs and exists.
Also some hints can be given for partial load reload of a component
So in cfg files we have
provides+name=foo # maybe id in the place of name?
provides.read-command=read blabla # default is the component read command
provides.start-stop=Xyz # default to the component start-stop
....
requires+name=foo
requires.order=a # default to nothing or 1?
requires.exist=b # default to nothing (0)
requires.needs=c # default to nothing
requires.read-command=read pouf # default is the component read command
requires.start-stop=Zyx # default to the component start-stop
4. Implementation. The order stuff is already perfectly implemented. I'm
really concerned about "minimal reloading". I will have some times
to work on this next week (I will have a lot of work from the 2 to the 11).
I think that it is not difficult to implement a first approximation
of "minimal reloading" without doing unuseful work for the future (and
even without the previous requires/provides implementation).
The set of components are the vertices of a graph, there is an edge
between two components A and B if there is a direct provides/requires
relation between A and B (A has requires/provides+name=foo and B has
provides/requires+name=foo; we may orient the edge, but this is not
necessary at first approximation). There is a dependence relation
between two components X and Y if there is a path from X to Y (not
oriented since the graph is not oriented and so the relation is symmetric).
This relation is the transitive closure of the graph relation and we have
a closure operation: if A is a component cl(A) is the connected
component of A. For a set S of components, cl(S) is the smallest
subset of the set of the components which contains S and such that
if Z is a component not in cl(S), Z is free over cl(S) (no dependence
(and in fact no direct provides/requires) relation with an element of
cl(S)). Sorry to be a bit pedantic, but this help me to think.
Now if we want to load a set S of components, we just have to compute
cl(S). I think this is easy to implement. Moreover, we should be able
to be more fine in the future, but the components that we should have to
reload will be a subset of cl(S).
I do not say that there are no problems. One is that all the dependency
relations have to be defined in the .cfg files (at the present time
alphabetic order help). An other one is that we have to rebuild
the themes-rc-2 file and need to update the theme management
menu but we surely not have to read themes-rc-2. A simple solution
is to add themes-menu. There is also a problem with the stop function.
Finally, I think we have to add a global variable to ft-config,
ENABLE_CCDS, set to 0 by default and the "new" code will apply if it
is set 1.
fvwm-2.4 is not very far I think, let us begin the CCDS!
Regards, Olivier
|
|
From: Olivier C. <oli...@fr...> - 2000-12-24 06:02:51
|
Mikhael Goikhman wrote: > > On 23 Dec 2000 01:39:25 +0100, Olivier Chapuis wrote: > > > > About utopia font: I need a real variable font, i.e., a font that can > > be of arbitrary size in a pretty way, I take the utopia font because it > > is in the 75dpi Mandrake package ... It seems that the font selector > > will have some portability problems: > > Do you have any -adobe-utopia-* font? > > Yes, all except for bold ones, probably RH forgot to include them. > With filter -adobe-*-bold-*-*-*-*-*-*-*-*-*-iso8859-1 there are families: > > courier [fixed], helvetica, new centure schoolbook and times [variable]. > All 4 are bold and medium, while -adobe-utopia-* only medium. > > > Do you use a font server as xfs? > > Yes, but can this be related? > Do not know, in fact I do not know the different between using or not a font server (but that with a font server we can use true type font). > > Can your Xserver generate "fixed" fonts of arbitrary pixels size > > (even horrible such fonts)? > > Do you mean something like -misc-fixed-*-*-*-*-21-*-*-*-*-*-*-* where 21 > is actually any size? Yes > BTW, a very nice tool. It is more capable and intuitive than gfontsel. > Still I think xfontsel is the most intuitive :), but of course it is not > as capable as FvwmScript-FontSelector. Just a new default choice "* (*)" > may be added to the "Family (Foundary)" list. > Thanks, it is a bit slow and this maybe fixed in the future, also there are still some bugs (in unlikely situation ...). Do you have some objections for having dot files under $FVWM_USERDIR for the FVWM Themes FvwmScript? Regards, Olivier |
|
From: Mikhael G. <mi...@co...> - 2000-12-24 04:47:19
|
On 23 Dec 2000 01:39:25 +0100, Olivier Chapuis wrote: > > About utopia font: I need a real variable font, i.e., a font that can > be of arbitrary size in a pretty way, I take the utopia font because it > is in the 75dpi Mandrake package ... It seems that the font selector > will have some portability problems: > Do you have any -adobe-utopia-* font? Yes, all except for bold ones, probably RH forgot to include them. With filter -adobe-*-bold-*-*-*-*-*-*-*-*-*-iso8859-1 there are families: courier [fixed], helvetica, new centure schoolbook and times [variable]. All 4 are bold and medium, while -adobe-utopia-* only medium. > Do you use a font server as xfs? Yes, but can this be related? > Can your Xserver generate "fixed" fonts of arbitrary pixels size > (even horrible such fonts)? Do you mean something like -misc-fixed-*-*-*-*-21-*-*-*-*-*-*-* where 21 is actually any size? Yes, I have both lines for each directory, like /usr/X11R6/lib/X11/fonts/100dpi with and without :unscaled postfix in my /etc/X11/fs/config (or XF86Config for that matter). BTW, a very nice tool. It is more capable and intuitive than gfontsel. Still I think xfontsel is the most intuitive :), but of course it is not as capable as FvwmScript-FontSelector. Just a new default choice "* (*)" may be added to the "Family (Foundary)" list. Regards, Mikhael. |
|
From: Olivier C. <oli...@fr...> - 2000-12-23 00:38:54
|
migo in the ChangeLog worte: > added forgotten file to cvs and tagged it, so hopefully > cvs update -r version-0_4_1 can be built without errors; > replaced some adobe-utopia-bold fonts used in the tool, so > it at least loaded for me (I am not sure about this, but I > have no, say, font -adobe-utopia-bold-r-normal-*-13-*-*-*-p-*-*-*). Ooops, thanks I only think to version 0.4.1 and completely forget the cvs (even if the font selector was not a 4.1 issue I add it to this version because it was in my machine when I've got the better occasion to upload version 0.4.1.) About utopia font: I need a real variable font, i.e., a font that can be of arbitrary size in a pretty way, I take the utopia font because it is in the 75dpi Mandrake package ... It seems that the font selector will have some portability problems: Do you have any -adobe-utopia-* font? Do you use a font server as xfs? Can your Xserver generate "fixed" fonts of arbitrary pixels size (even horrible such fonts)? Thanks, Olivier |
|
From: Olivier C. <oli...@fr...> - 2000-12-23 00:24:58
|
Hello, I've added to ft-config a cfg cache file. The method I use is obvious and moreover I have added some "#ccf ..." so that it is easy to see the diff (if you remove all the #ccf codes you will obtain the old code). The idea is to dump the themes config into a file $userDir/.cfg-cache.pl, if this file does not exit or in the case of a "restore default" or a "refresh" (nothing with --site). If the file exist the themes cfg is loaded from it. Of course, ft-config is slower when it has to create the cache file, but it is faster in "normal" use. At the end of the message there is an example of speed comparison using DProf (same themes situation in the tests). We get something like 30% of speed up (almost 1 sec in my machine). But the time to look for is the CumulS for main::loadThemeCfg and here we see that the ccf code is 2.5 times faster than the old code (we may win a little bit more by applying the same method to the "current" theme too). I do not say that the ccf method is perfect. However, it gives a not negligible speed up with no real changes in the ft-config logic. Also, we have to add a new option: one refresh will rebuild the cache the other one will not. An other possible avantage of the methode is that we may in the future do more work (which may take "a lot of" time) when parsing the .cfg files, e.g., checking if fvwm2 is compiled with stroke and remove this option of the settings if not. Olivier Before the ccf patch: [olivier@snoopy bin]$ dprofpp tnn-ts-1 User+System Time = 2.775177 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 34.2 0.950 0.948 498 0.0019 0.0019 main::decodeCfgEntry 14.3 0.397 1.513 29 0.0137 0.0522 main::loadThemeCfg 5.41 0.150 0.150 32 0.0047 0.0047 main::loadFile 3.60 0.100 0.100 2 0.0500 0.0500 AutoLoader::AUTOLOAD 3.24 0.090 0.195 1317 0.0001 0.0001 main::clonePerlValue 2.88 0.080 0.079 189 0.0004 0.0004 main::isArrayElement 2.52 0.070 0.155 218 0.0003 0.0007 main::encodeCfgEntry 1.80 0.050 0.140 9 0.0056 0.0155 Getopt::Long::BEGIN 1.44 0.040 0.050 1 0.0400 0.0500 vars::BEGIN 1.44 0.040 0.039 1 0.0397 0.0393 Fvwm::ThemeCfg::getSortedComponentsToRead 1.41 0.039 0.067 1 0.0391 0.0668 Fvwm::ThemeCfg::getOwnThemeSubMenusRc 1.08 0.030 0.030 2 0.0150 0.0150 Exporter::export 1.08 0.030 0.029 332 0.0001 0.0001 Fvwm::ThemeCfg::getComponentCfg 1.08 0.030 1.472 1 0.0300 1.4718 Fvwm::ThemeCfg::generateThemesRc 0.72 0.020 0.019 174 0.0001 0.0001 main::escapeMenuName After the ccf patch: [olivier@snoopy bin]$ dprofpp tcc-ts-1 User+System Time = 1.837672 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 18.5 0.340 0.340 1 0.3400 0.3400 main::loadCfgCacheFile 9.25 0.170 0.170 39 0.0044 0.0044 main::decodeCfgEntry 5.99 0.110 0.278 1317 0.0001 0.0002 main::clonePerlValue 4.90 0.090 0.090 2 0.0450 0.0450 AutoLoader::AUTOLOAD 4.35 0.080 0.162 218 0.0004 0.0007 main::encodeCfgEntry 3.81 0.070 0.599 29 0.0024 0.0207 main::loadThemeCfg 3.27 0.060 0.058 189 0.0003 0.0003 main::isArrayElement 2.72 0.050 0.060 1 0.0500 0.0600 vars::BEGIN 2.61 0.048 0.074 1 0.0484 0.0743 Fvwm::ThemeCfg::getOwnThemeSubMenusRc 2.18 0.040 0.140 9 0.0044 0.0155 Getopt::Long::BEGIN 2.12 0.039 0.039 1 0.0394 0.0388 Fvwm::ThemeCfg::getSortedComponentsToRead 1.63 0.030 0.030 2 0.0150 0.0150 Exporter::export 1.63 0.030 0.914 360 0.0001 0.0025 Fvwm::ThemeCfg::AUTOLOAD 1.52 0.028 0.158 1 0.0281 0.1584 Fvwm::ThemeCfg::getAllThemeSubMenusRc 1.09 0.020 0.020 1 0.0200 0.0200 main::loadFile PS: I also make some tests with: time fvwm-themes-config --show-themes and the new code is more than 2 times faster. |
|
From: Olivier C. <oli...@fr...> - 2000-12-20 12:47:28
|
Hello, I've released version 0.4.1. I've also updated the ChangeLog and the NEWS files of our home page (sourceforge). Strange things happen with sourceforge (I've fixed the little ssh problem mentioned by sourceforge): * I do not receive the mail that announce the release as usual. * scp1 does not work (so I've not upload rpm's to pub/rpm) Finally I've released a freshmeat announce. Olivier |
|
From: <MIS...@ao...> - 2000-12-20 10:40:48
|
Dude Paul, Rob you guys have got to check these videos out. -Kieth =20 ----------------- Forwarded Message:=20 Subj: =95 Britney Spears Fucking & Sucking!! =95 Date: 12/4/00 6:20:26PM From: no...@pa... (PassThisOn.com Notification For Carmen) To: cm...@ao... (Carmen) You want access to the <b>hotest</b> Britney Spears videos? <a=20 href=3D"http://www.geocities.com/dfr65yds/">Click Here</a> for <b>instant=20 access</b> to our exclusive Britney Spears archives. =20 |
|
From: Olivier C. <oli...@fr...> - 2000-12-14 11:44:22
|
Olivier Chapuis wrote: > > Mikhael Goikhman wrote: > > > > I don't have enough free time for some period, but I hope to have it soon. > > > > Olivier, can you release a new fvwm-themes version? > > Yes, I will release a new version the 12 or the 13 of december (I will > have a fast internet connection). Seems that sourceforge is broken today and will be broken the 15th. So I will release a new version the 20th. Olivier |
|
From: Olivier C. <oli...@fr...> - 2000-12-14 08:48:08
|
Alex Wallis wrote: > > Olivier Chapuis wrote: > > > > 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. > > > > > > > > - what is the value of your $LANG variable? en I imagine. > > This may be the problem. I got nothing from echo $LANG but even setting > it manually with "export LANG=en" didn't help at all. Somehow I still > suspect there's something incompatible with my system. Yes, this s may be the problem. In fact, this is surely a problem, I think that I've fixed this in my last commit. Can you try again? Olivier |
|
From: Alex W. <aw...@do...> - 2000-12-14 07:18:04
|
I've been successfully using a simple shell script for some time to update my cvs sources, compile, and install both fvwm and fvwm-themes. I have to be the first to admit that my scripting skills are far less than adequate, but I've been thinking that such a script if written properly, and placed on the new fvwm.themes.org site might help to encourage new users that might otherwise be using another WM. The script I use is at http://dove.net.au/~awol/fvwm2/upgrade-cvs-fvwm-themes and there's an install-cvs-fvwm-themes script too. They are primarily intended for installing on a SuSE linux box. If anyone would care to improve upon this script, then it or a better one could perhaps be suitable for inclusion on the new website. A working example of the site so far is at http://dove.net.au/~awol/fvwm2/fvwm.themes.org/ This is definately going to change though, and some help with some extra graphics would be appreciated. Volunteers? TIA Alex |
|
From: Alex W. <aw...@do...> - 2000-12-14 03:14:41
|
Olivier Chapuis wrote: > > 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. > > > > Outch! > I cannot reproduce this. > Can you: > - update to the last cvs code (I'm image that you already do this). I "cvs update" on a regular almost daily basis. > - Try again and send me any errors output. No obvious errors are produced. The GUI's still mostly work ok. > - what is the value of your $LANG variable? en I imagine. This may be the problem. I got nothing from echo $LANG but even setting it manually with "export LANG=en" didn't help at all. Somehow I still suspect there's something incompatible with my system. > - See if fvwm-themes-config run when the ConfigCenter run. awol 26713 1.5 2.6 3052 1664 13 S 13:14 0:01 /opt/fvwm/libexec/fvwm/2.3.26/FvwmScript 21 4 none 0 8 FvwmScript-ConfigCenter --text-colorset 34 --i awol 26719 2.7 3.5 3432 2232 13 S 13:14 0:03 perl -w /opt/fvwm/bin/fvwm-themes-script --config-center --com-name=script-26713 > - See if fvwm-themes-script run when the ThemesCenter run. awol 24507 0.2 2.0 2700 1308 13 S 21:49 0:00 /opt/fvwm/libexec/fvwm/2.3.26/FvwmScript 21 4 none 0 8 FvwmScript-ThemesCenter --text-colorset 34 --v awol 24518 5.1 4.9 4280 3096 13 S 21:49 0:20 perl -w /opt/fvwm/bin/fvwm-themes-config --com-mode --com-name=config-24507 No, they look back to front! > - Try the help button in the ThemesCenter (2nd button from the right). All menu bar buttons(along titlebar) produce core dump and crash. However my machine never leaves a core file. > - do you have the folowing files: > where_fvwm-themes_is_installed/locale/en/FvwScript-ThemesCenter.msg /opt/fvwm/locale/en/FvwmScript-ThemesCenter.msg > where_fvwm-themes_is_installed/locale/en/FvwScript-ConfigCenter.msg /opt/fvwm/locale/en/FvwmScript-ConfigCenter.msg Yes, I have those files and others. Sorry this is taking so long. I'm really stumped. Thanks for all your hard work! :) Alex P.S.I did however notice that I have Insure++4.1 installed on my machine, but I have no idea how to use it. I only mention it because of your other mails to the lists about it. I suspect I have lots of other helpful debugging tools also since I installed about 5Gb of SuSE software. C'est la vie! |
6 messages has been excluded from this view by a project administrator.
