Re: Question about menus (usermenu, appmenu)
On Sat, 22 Aug 2015, Josip Deanovic wrote: On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: Which feature was removed that you are missing? The one I am talking for over a year now. :-) Also app icon caching was broken around the same time. The app icon cache in CachedPixmaps was meant to store icons retrieved from X clients so the dock or clip can display those when the client is not running like after startup. The cache should contain only such icons and the path should never appear in WMWindowAttributes because the cache is an internal thing used to look up icons not otherwise available. If you look at your WMWindowAttributes now it is full of entries referring to the cache that should not be there and if you look at the cache dir you'll find a lot of icons from all apps you've ever started while there should be only the few docked ones that use client side icons. Also the cache is never cleaned up only new icons are added to it. The icon handling code was a bit complicated before but worked (maybe cache cleanup was broken before) until overzealous simplification attempts have messed it up so much that it is now difficult to untangle. Even more so because the object oriented design was also messed up by renaming and moving methods around so now it is not clear what object methods these functions were meant to be. I think the principles to follow should be: 1. K.I.S.S. 2. If ain't broke don't fix it. 3. If you don't understand it don't touch it. (That is, think about all possible implications of your proposed change because it may work with your particular settings but a lot of things can be set by preferences.) Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH (whome)] Update wmcalc on dockapps webpage.
--- dockapps/dockapps.db | 1 + 1 file changed, 1 insertion(+) diff --git a/dockapps/dockapps.db b/dockapps/dockapps.db index 65be3ad..b64eccf 100644 --- a/dockapps/dockapps.db +++ b/dockapps/dockapps.db @@ -173,6 +173,7 @@ dockapps = 241 category = General/Others [wmcalc] +version-0.6 = 43ddcdfb2b03a3ad66b368ed635cf942d8a629b4 version-0.5 = c2f0ad2882b89c5c33dfb8331c1f05ca284e7c36 version-0.4 = 8c0d48a6e55bb901cd1217e8a78601e1ab36a6a4 image = wmcalcscr3.jpg -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Hi Josip,
thanks for your report. Sorry about that. Patch is attached.
Perhaps we should use a different flag to run the application more
times from the same dock icon.
Cheers,
kix
Josip Deanovic escribió:
On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote:
On Sat, 22 Aug 2015 at 15:11:33 +0200, Josip Deanovic wrote:
> Let's not remove anything until we find out what this really is.
> There are some features still missing because of such actions in
> the past.
Which feature was removed that you are missing?
The one I am talking for over a year now. :-)
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
For the complete thread look for a subject "Double-click on application in
wmdock does not launch the application if one instance is already
running".
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
>From ccff70a14d18fb68b2869f1fe05d6069c9552b26 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20=28kix=29?=
Date: Sun, 23 Aug 2015 17:33:38 +0200
Subject: [PATCH] create_appicon_from_dock checks if no_appicon flag is set
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
As Josip Deanovic reported:
---8<---
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
---8<---
This patch reverts this change (not the patch). Now the function
create_appicon_from_dock checks if the flag no_appicon is set,
and then, do not execute the code related to the appicon.
Signed-off-by: Rodolfo García Peñas (kix)
---
src/appicon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/appicon.c b/src/appicon.c
index 302066d..08331c7 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -1180,7 +1180,7 @@ static void create_appicon_from_dock(WWindow *wwin, WApplication *wapp, Window m
}
/* If created, then set some flags */
- if (wapp->app_icon) {
+ if (wapp->app_icon && !WFLAGP(wapp->main_window_desc, no_appicon)) {
WWindow *mainw = wapp->main_window_desc;
wapp->app_icon->running = 1;
--
2.5.0
Re: Question about menus (usermenu, appmenu)
Hi Carlos,
yes. I just sent the patch. Window Maker sometimes checks the flags,
sometimes only the pointers.
Cheers,
kix
"Carlos R. Mafra" escribió:
Rodolfo? Any ideas here?
On Sat, 22 Aug 2015 at 18:04:27 +0200, Josip Deanovic wrote:
On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote:
> On Sat, 22 Aug 2015 at 15:11:33 +0200, Josip Deanovic wrote:
> > Let's not remove anything until we find out what this really is.
> > There are some features still missing because of such actions in
> > the past.
>
> Which feature was removed that you are missing?
The one I am talking for over a year now. :-)
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
For the complete thread look for a subject "Double-click on application in
wmdock does not launch the application if one instance is already
running".
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
On Sunday 2015-08-23 15:41:04 Rodolfo García Peñas wrote: > Hi Josip, > > thanks for your report. Sorry about that. Patch is attached. > > Perhaps we should use a different flag to run the application more > times from the same dock icon. I have no objections to that as long as that feature exists and the option is intuitive and logical and doesn't break anything else. :-) Note that in older Windowmaker versions (up until (and I think including but I am not sure any more) 0.95.3) double click on the docked icon could be used to execute multiple instances of the application only if the window attributes of the application are set so that application icon is disabled for that specific application (it's in the window attributes options under the Application Specific menu and the option is represented as "No application icon"). -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
On Sunday 2015-08-23 11:25:57 BALATON Zoltan wrote: > On Sat, 22 Aug 2015, Josip Deanovic wrote: > > On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: > >> Which feature was removed that you are missing? > > > > The one I am talking for over a year now. :-) > > Also app icon caching was broken around the same time. The app icon > cache in CachedPixmaps was meant to store icons retrieved from X > clients so the dock or clip can display those when the client is not > running like after startup. The cache should contain only such icons > and the path should never appear in WMWindowAttributes because the > cache is an internal thing used to look up icons not otherwise > available. If you look at your WMWindowAttributes now it is full of > entries referring to the cache that should not be there and if you look > at the cache dir you'll find a lot of icons from all apps you've ever > started while there should be only the few docked ones that use client > side icons. Also the cache is never cleaned up only new icons are added > to it. > > The icon handling code was a bit complicated before but worked (maybe > cache cleanup was broken before) until overzealous simplification > attempts have messed it up so much that it is now difficult to > untangle. Even more so because the object oriented design was also > messed up by renaming and moving methods around so now it is not clear > what object methods these functions were meant to be. > > I think the principles to follow should be: > > 1. K.I.S.S. > 2. If ain't broke don't fix it. > 3. If you don't understand it don't touch it. (That is, think about all > possible implications of your proposed change because it may work > with your particular settings but a lot of things can be set by > preferences.) > > Regards, > BALATON Zoltan I have noticed that something has changed several years ago regarding this but didn't give much attention to it. Good thing that you have summarized it like this. I wonder if Carlos is able to keep track of all the confirmed and unconfirmed reports that appear on the list through the years. I mean, this report could also get forgotten unless someone continues to remind people about it. Maybe it would be a good idea to start a thread about the bug report and feature request page semi-independent of this list. I know that there was some initiative in the past and I wouldn't like that it grows into a conflict over different solutions and code maintenance again. I like things the way they are and as a user I just feel the need for bug and feature-request report page. That would help users and developers to see what is already reported, what needs to be tested (in order to confirm the potential bug) and what is still waiting to be fixed. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sun, 23 Aug 2015 at 18:16:32 +0200, Josip Deanovic wrote: > On Sunday 2015-08-23 15:41:04 Rodolfo García Peñas wrote: > > Hi Josip, > > > > thanks for your report. Sorry about that. Patch is attached. Thank you, Rodolfo. Josip, the patch should fix the issue and it's in the #next branch already. Would you mind testing it? > > Perhaps we should use a different flag to run the application more > > times from the same dock icon. > > I have no objections to that as long as that feature exists and the > option is intuitive and logical and doesn't break anything else. :-) Note that the issue you found is not intuitive nor logical :-) There is no reason why the setting of the "No application icon" should have an effect on being able to execute multiple instances of a docked application. The "No application icon" option should control just the application icon, nothing else. So what Rodolfo did originally was correct -- he enforced the behavior that the option stands for. The "execute multiple instances" happened to work before by chance. But nevermind, a regression is a regression and thank you for reporting it multiple times; it should work again with the latest patch but ideally this behavior should not be coupled with this particular option. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: > On Sun, 23 Aug 2015 at 18:16:32 +0200, Josip Deanovic wrote: > > On Sunday 2015-08-23 15:41:04 Rodolfo García Peñas wrote: > > > Hi Josip, > > > > > > thanks for your report. Sorry about that. Patch is attached. > > Thank you, Rodolfo. Yes, thank you from me too. > Josip, the patch should fix the issue and it's in the #next > branch already. Would you mind testing it? I'll test it in the next 30 minutes. > > > Perhaps we should use a different flag to run the application more > > > times from the same dock icon. > > > > I have no objections to that as long as that feature exists and the > > option is intuitive and logical and doesn't break anything else. :-) > > Note that the issue you found is not intuitive nor logical :-) I didn't find it, my friend pointed it to me and I somehow still remembered that feature from like 20 years ago so I needed to inspect it to confirm that it actually stopped working few years ago. Anyway I didn't put that feature there but it's handy. :-) > There is no reason why the setting of the "No application icon" should > have an effect on being able to execute multiple instances of a docked > application. The "No application icon" option should control just the > application icon, nothing else. I agree. > So what Rodolfo did originally was correct -- he enforced the behavior > that the option stands for. The "execute multiple instances" happened > to work before by chance. > > But nevermind, a regression is a regression and thank you for > reporting it multiple times; it should work again with the latest > patch but ideally this behavior should not be coupled with this > particular option. It would be nice to decouple them then. It would help to avoid loosing the feature in the future. I would suggest adding another option to the Application Specific menu of the Window attributes window. There is a plenty of space there and the only thing that is left to discuss in that case is whether this option should work only in case application icons are disabled for the specific docked application or always. If the option is allowed to be activated even if the application icon is not disabled that could produce some confusion. So in my opinion, ideally the new option should be inactive (disabled/grayed-out) unless the "No application icon" is selected. And by default the new option should be disabled (unselected) by default. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip DeanovicOn Sunday 2015-08-23 19:25:32 wrote: > On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: > > Josip, the patch should fix the issue and it's in the #next > > branch already. Would you mind testing it? > > I'll test it in the next 30 minutes. Ok, I have tested it and I can confirm that feature now works but while testing it I have encountered undesirable issues such as windowmaker crash and restart. So this is the procedure I used while testing: 1. I am using kwrite application for my tests 2. Start kwrite application on the command line 3. Checking Application Specific window attributes - No application icon - unselected - Shared application icon - selected 4. Drag the application icon to the dock 5. Enable (select) the option No application icon for the application 6. Close the application and run multiple instances of the application using double-click on the docked icon - everything works fine 7. In the application Specific menu disable (unselect) the option No application icon - windowmaker crashes and restarts -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sun, 23 Aug 2015 at 19:25:32 +0200, Josip Deanovic wrote: > On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: > > On Sun, 23 Aug 2015 at 18:16:32 +0200, Josip Deanovic wrote: > > > On Sunday 2015-08-23 15:41:04 Rodolfo García Peñas wrote: > > > > Hi Josip, > > > > > > > > thanks for your report. Sorry about that. Patch is attached. > > > > Thank you, Rodolfo. > > Yes, thank you from me too. > > > Josip, the patch should fix the issue and it's in the #next > > branch already. Would you mind testing it? > > I'll test it in the next 30 minutes. > > > > > Perhaps we should use a different flag to run the application more > > > > times from the same dock icon. > > > > > > I have no objections to that as long as that feature exists and the > > > option is intuitive and logical and doesn't break anything else. :-) > > > > Note that the issue you found is not intuitive nor logical :-) > > I didn't find it, my friend pointed it to me and I somehow still > remembered that feature from like 20 years ago so I needed to inspect > it to confirm that it actually stopped working few years ago. > > Anyway I didn't put that feature there but it's handy. :-) > > > There is no reason why the setting of the "No application icon" should > > have an effect on being able to execute multiple instances of a docked > > application. The "No application icon" option should control just the > > application icon, nothing else. > > I agree. > > > So what Rodolfo did originally was correct -- he enforced the behavior > > that the option stands for. The "execute multiple instances" happened > > to work before by chance. > > > > But nevermind, a regression is a regression and thank you for > > reporting it multiple times; it should work again with the latest > > patch but ideally this behavior should not be coupled with this > > particular option. > > It would be nice to decouple them then. > It would help to avoid loosing the feature in the future. > I would suggest adding another option to the Application Specific > menu of the Window attributes window. > > There is a plenty of space there and the only thing that is left > to discuss in that case is whether this option should work only in > case application icons are disabled for the specific docked application > or always. > > If the option is allowed to be activated even if the application icon > is not disabled that could produce some confusion. > So in my opinion, ideally the new option should be inactive > (disabled/grayed-out) unless the "No application icon" is selected. > And by default the new option should be disabled (unselected) by default. Perhaps it would be better to not even have an option for this, it should always be possible to execute a docked app multiple times. And indeed, one needs to think about what to do with the appicons. Perhaps just silently behaving as "no appicon" is set starting from the second instance, I don't know. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:48:27 Carlos R. Mafra wrote: > Perhaps it would be better to not even have an option for this, > it should always be possible to execute a docked app multiple times. It already is but only if you use right click and Launch menu option. Double-click has different behavior based on whether the "No application icon" is enabled or not for a specific application. I have checked and described the behavior thoroughly in the thread with the subject: "Double-click on application in wmdock does not launch the application if one instance is already running" > And indeed, one needs to think about what to do with the appicons. > Perhaps just silently behaving as "no appicon" is set starting from > the second instance, I don't know. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip Deanovic escribió: Josip DeanovicOn Sunday 2015-08-23 19:25:32 wrote: On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: > Josip, the patch should fix the issue and it's in the #next > branch already. Would you mind testing it? I'll test it in the next 30 minutes. Ok, I have tested it and I can confirm that feature now works but while testing it I have encountered undesirable issues such as windowmaker crash and restart. So this is the procedure I used while testing: 1. I am using kwrite application for my tests 2. Start kwrite application on the command line 3. Checking Application Specific window attributes - No application icon - unselected - Shared application icon - selected 4. Drag the application icon to the dock 5. Enable (select) the option No application icon for the application 6. Close the application and run multiple instances of the application using double-click on the docked icon - everything works fine 7. In the application Specific menu disable (unselect) the option No application icon - windowmaker crashes and restarts -- Josip Deanovic Hi Josip, confirmed, I am working on it. Thanks Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:32:06 Rodolfo García Peñas wrote: > Hi Josip, > > confirmed, I am working on it. > > Thanks Cool. Thank you. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 0/7] Icon patches
I included here the patches to solve the problems reported by Josip and Zoltan. Please, test these changes before apply to the repo. Rodolfo García Peñas (kix) (7): create_appicon_from_dock checks if no_appicon flag is set New applications do not create Cached Icon Remove unused argument in save_appicon Avoid recreate Cached icon moving between docks Avoid create again a docked application cache icon save the icon filename instead the full path Remove cache icon when detached src/appicon.c | 10 +++--- src/appicon.h | 2 +- src/dock.c| 11 +++ src/icon.c| 50 ++ src/icon.h| 1 + 5 files changed, 54 insertions(+), 20 deletions(-) -- 2.5.0 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 2/7] New applications do not create Cached Icon
This patch avoids to create Cached Icons for all applications. Only the applications docked should create it, as Zoltan said: ---8<--- Also app icon caching was broken around the same time. The app icon cache in CachedPixmaps was meant to store icons retrieved from X clients so the dock or clip can display those when the client is not running like after startup. The cache should contain only such icons and the path should never appear in WMWindowAttributes because the cache is an internal thing used to look up icons not otherwise available. If you look at your WMWindowAttributes now it is full of entries referring to the cache that should not be there and if you look at the cache dir you'll find a lot of icons from all apps you've ever started while there should be only the few docked ones that use client side icons. Also the cache is never cleaned up only new icons are added to it. ---8<--- Signed-off-by: Rodolfo García Peñas (kix) --- src/appicon.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/appicon.c b/src/appicon.c index 08331c7..2a9db5c 100644 --- a/src/appicon.c +++ b/src/appicon.c @@ -159,9 +159,6 @@ void create_appicon_for_application(WApplication *wapp, WWindow *wwin) if (!WFLAGP(wapp->main_window_desc, no_appicon)) paint_app_icon(wapp); } - - /* Save the app_icon in a file */ - save_appicon(wapp->app_icon, False); } void unpaint_app_icon(WApplication *wapp) -- 2.5.0 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 1/7] create_appicon_from_dock checks if no_appicon flag is set
As Josip Deanovic reported:
---8<---
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
---8<---
This patch reverts this change (not the patch). Now the function
create_appicon_from_dock checks if the flag no_appicon is set,
and then, do not execute the code related to the appicon.
Because the connection between the icon and the window is broken
(icon->owner is null) we need check if the icon->owner exists
when we try to re-create the icon in the Window Attributes window.
Signed-off-by: Rodolfo García Peñas (kix)
---
src/appicon.c | 2 +-
src/icon.c| 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/appicon.c b/src/appicon.c
index 302066d..08331c7 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -1180,7 +1180,7 @@ static void create_appicon_from_dock(WWindow *wwin,
WApplication *wapp, Window m
}
/* If created, then set some flags */
- if (wapp->app_icon) {
+ if (wapp->app_icon && !WFLAGP(wapp->main_window_desc, no_appicon)) {
WWindow *mainw = wapp->main_window_desc;
wapp->app_icon->running = 1;
diff --git a/src/icon.c b/src/icon.c
index 721c428..a04e11b 100644
--- a/src/icon.c
+++ b/src/icon.c
@@ -748,7 +748,12 @@ RImage *get_rimage_icon_from_wm_hints(WIcon *icon)
{
RImage *image = NULL;
unsigned int w, h, d;
- WWindow *wwin = icon->owner;
+ WWindow *wwin;
+
+ if ((!icon) || (!icon->owner))
+ return NULL;
+
+ wwin = icon->owner;
if (!getSize(wwin->wm_hints->icon_pixmap, &w, &h, &d)) {
icon->owner->wm_hints->flags &= ~IconPixmapHint;
--
2.5.0
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 7/7] Remove cache icon when detached
This pach removes the icon from the icon cache when the icon is
detached from the dock/clip.
That helps to hold tidy the icon cache folder.
---8<---
Also app icon caching was broken around the same time. The app icon cache
in CachedPixmaps was meant to store icons retrieved from X clients so the
dock or clip can display those when the client is not running like after
startup. The cache should contain only such icons and the path should never
appear in WMWindowAttributes because the cache is an internal thing used to
look up icons not otherwise available. If you look at your WMWindowAttributes
now it is full of entries referring to the cache that should not be there and
if you look at the cache dir you'll find a lot of icons from all apps you've
ever started while there should be only the few docked ones that use client
side icons. Also the cache is never cleaned up only new icons are added to it.
---8<---
Signed-off-by: Rodolfo García Peñas (kix)
---
src/dock.c | 4
src/icon.c | 18 ++
src/icon.h | 1 +
3 files changed, 23 insertions(+)
diff --git a/src/dock.c b/src/dock.c
index e27b28a..3b3313b 100644
--- a/src/dock.c
+++ b/src/dock.c
@@ -2425,6 +2425,9 @@ void wDockDetach(WDock *dock, WAppIcon *icon)
dock->icon_count--;
+ /* Remove the Cached Icon */
+ remove_cache_icon(icon->icon->file);
+
/* if the dock is not attached to an application or
* the application did not set the appropriate hints yet,
* destroy the icon */
@@ -2452,6 +2455,7 @@ void wDockDetach(WDock *dock, WAppIcon *icon)
if (wPreferences.auto_arrange_icons)
wArrangeIcons(dock->screen_ptr, True);
}
+
if (dock->auto_collapse || dock->auto_raise_lower)
clipLeave(dock);
}
diff --git a/src/icon.c b/src/icon.c
index d53f756..0dbd6ac 100644
--- a/src/icon.c
+++ b/src/icon.c
@@ -529,6 +529,24 @@ char *wIconStore(WIcon *icon)
return filename;
}
+void remove_cache_icon(char *filename)
+{
+ char *cachepath;
+
+ if (!filename)
+ return;
+
+ cachepath = get_icon_cache_path();
+ if (!cachepath)
+ return;
+
+ /* Filename check/parse could be here */
+ if (!strncmp(filename, cachepath, strlen(cachepath)))
+ unlink(filename);
+
+ wfree(cachepath);
+}
+
static void cycleColor(void *data)
{
WIcon *icon = (WIcon *) data;
diff --git a/src/icon.h b/src/icon.h
index dbcb289..cccd7a8 100644
--- a/src/icon.h
+++ b/src/icon.h
@@ -80,4 +80,5 @@ void wIconSetHighlited(WIcon *icon, Bool flag);
void set_icon_image_from_image(WIcon *icon, RImage *image);
void set_icon_minipreview(WIcon *icon, RImage *image);
+void remove_cache_icon(char *filename);
#endif /* WMICON_H_ */
--
2.5.0
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 4/7] Avoid recreate Cached icon moving between docks
This patch avoids to create again the icon in the Cache if the icon was in other Dock/Clip/Drawer, becasue the icon was previously created and exits. Signed-off-by: Rodolfo García Peñas (kix) --- src/dock.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/dock.c b/src/dock.c index fce3f5b..e27b28a 100644 --- a/src/dock.c +++ b/src/dock.c @@ -2344,7 +2344,6 @@ Bool wDockMoveIconBetweenDocks(WDock *src, WDock *dest, WAppIcon *icon, int x, i icon->icon->shadowed = 0; update_icon = True; } - save_appicon(icon); } if (src->auto_collapse || src->auto_raise_lower) -- 2.5.0 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 6/7] save the icon filename instead the full path
This patch saves the icon filename in the database and in the disk. wmaker
can find the icon in the different folders, including the cache folder.
This patch is based in the comments of Zoltan:
---8<---
Also app icon caching was broken around the same time. The app icon cache
in CachedPixmaps was meant to store icons retrieved from X clients so the
dock or clip can display those when the client is not running like after
startup. The cache should contain only such icons and the path should never
appear in WMWindowAttributes because the cache is an internal thing used to
look up icons not otherwise available. If you look at your WMWindowAttributes
now it is full of entries referring to the cache that should not be there and
if you look at the cache dir you'll find a lot of icons from all apps you've
ever started while there should be only the few docked ones that use client
side icons. Also the cache is never cleaned up only new icons are added to it.
---8<---
Signed-off-by: Rodolfo García Peñas (kix)
---
src/icon.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/src/icon.c b/src/icon.c
index a04e11b..d53f756 100644
--- a/src/icon.c
+++ b/src/icon.c
@@ -470,7 +470,7 @@ static RImage *get_wwindow_image_from_wmhints(WWindow
*wwin, WIcon *icon)
*/
char *wIconStore(WIcon *icon)
{
- char *path, *dir_path, *file;
+ char *path, *dir_path, *file, *filename;
int len = 0;
RImage *image = NULL;
WWindow *wwin = icon->owner;
@@ -488,15 +488,23 @@ char *wIconStore(WIcon *icon)
return NULL;
}
- len = strlen(dir_path) + strlen(file) + 5;
+ /* Create the file name */
+ len = strlen(file) + 5;
+ filename = wmalloc(len);
+ snprintf(filename, len, "%s.xpm", file);
+ wfree(file);
+
+ /* Create the full path, including the filename */
+ len = strlen(dir_path) + strlen(filename) + 1;
path = wmalloc(len);
- snprintf(path, len, "%s%s.xpm", dir_path, file);
+ snprintf(path, len, "%s%s", dir_path, filename);
wfree(dir_path);
- wfree(file);
/* If icon exists, exit */
- if (access(path, F_OK) == 0)
- return path;
+ if (access(path, F_OK) == 0) {
+ wfree(path);
+ return filename;
+ }
if (wwin->net_icon_image)
image = RRetainImage(wwin->net_icon_image);
@@ -505,17 +513,20 @@ char *wIconStore(WIcon *icon)
if (!image) {
wfree(path);
+ wfree(filename);
return NULL;
}
if (!RSaveImage(image, path, "XPM")) {
wfree(path);
+ wfree(filename);
path = NULL;
}
+ wfree(path);
RReleaseImage(image);
- return path;
+ return filename;
}
static void cycleColor(void *data)
--
2.5.0
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip Deanovic escribió: On Sunday 2015-08-23 18:32:06 Rodolfo García Peñas wrote: Hi Josip, confirmed, I am working on it. Thanks Cool. Thank you. Solved. Thanks for your report. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 5/7] Avoid create again a docked application cache icon
This patch avoids to create again the cache icon for a docked application. If the application is docked, then the icon was previosly created. Signed-off-by: Rodolfo García Peñas (kix) --- src/appicon.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/appicon.c b/src/appicon.c index 9028d0e..8eb668f 100644 --- a/src/appicon.c +++ b/src/appicon.c @@ -1190,7 +1190,6 @@ static void create_appicon_from_dock(WWindow *wwin, WApplication *wapp, Window m /* Paint it */ wAppIconPaint(wapp->app_icon); - save_appicon(wapp->app_icon); } } -- 2.5.0 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 3/7] Remove unused argument in save_appicon
The argument dock is always True, so can be removed.
Signed-off-by: Rodolfo García Peñas (kix)
---
src/appicon.c | 6 +++---
src/appicon.h | 2 +-
src/dock.c| 8
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/appicon.c b/src/appicon.c
index 2a9db5c..9028d0e 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -433,14 +433,14 @@ void wAppIconPaint(WAppIcon *aicon)
}
/* Save the application icon, if it's a dockapp then use it with dock = True */
-void save_appicon(WAppIcon *aicon, Bool dock)
+void save_appicon(WAppIcon *aicon)
{
char *path;
if (!aicon)
return;
- if (dock && (!aicon->docked || aicon->attracted))
+ if (!aicon->docked || aicon->attracted)
return;
path = wIconStore(aicon->icon);
@@ -1190,7 +1190,7 @@ static void create_appicon_from_dock(WWindow *wwin,
WApplication *wapp, Window m
/* Paint it */
wAppIconPaint(wapp->app_icon);
- save_appicon(wapp->app_icon, True);
+ save_appicon(wapp->app_icon);
}
}
diff --git a/src/appicon.h b/src/appicon.h
index eb1904b..44913b8 100644
--- a/src/appicon.h
+++ b/src/appicon.h
@@ -78,7 +78,7 @@ void wAppIconPaint(WAppIcon *aicon);
void wAppIconMove(WAppIcon *aicon, int x, int y);
void create_appicon_for_application(WApplication *wapp, WWindow *wwin);
void removeAppIconFor(WApplication * wapp);
-void save_appicon(WAppIcon *aicon, Bool dock);
+void save_appicon(WAppIcon *aicon);
void paint_app_icon(WApplication *wapp);
void unpaint_app_icon(WApplication *wapp);
void wApplicationExtractDirPackIcon(const char *path, const char *wm_instance,
diff --git a/src/dock.c b/src/dock.c
index 99c137a..fce3f5b 100644
--- a/src/dock.c
+++ b/src/dock.c
@@ -583,7 +583,7 @@ static void keepIconsCallback(WMenu *menu, WMenuEntry
*entry)
wAppIconPaint(aicon);
}
}
- save_appicon(aicon, True);
+ save_appicon(aicon);
}
WMFreeArray(selectedIcons);
}
@@ -1445,7 +1445,7 @@ static void dockIconPaint(WAppIcon *btn)
wDrawerIconPaint(btn);
} else {
wAppIconPaint(btn);
- save_appicon(btn, True);
+ save_appicon(btn);
}
}
@@ -2219,7 +2219,7 @@ Bool wDockAttachIcon(WDock *dock, WAppIcon *icon, int x,
int y, Bool update_icon
wAppIconPaint(icon);
/* Save it */
- save_appicon(icon, True);
+ save_appicon(icon);
if (wPreferences.auto_arrange_icons)
wArrangeIcons(dock->screen_ptr, True);
@@ -2344,7 +2344,7 @@ Bool wDockMoveIconBetweenDocks(WDock *src, WDock *dest,
WAppIcon *icon, int x, i
icon->icon->shadowed = 0;
update_icon = True;
}
- save_appicon(icon, True);
+ save_appicon(icon);
}
if (src->auto_collapse || src->auto_raise_lower)
--
2.5.0
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > Solved. > > Thanks for your report. Thank you for the effort. I have just tested the code from the fresh next branch and the issue still exist (Windowmaker crashes and restarts). -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic : On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: Solved. Thanks for your report. Thank you for the effort. I have just tested the code from the fresh next branch and the issue still exist (Windowmaker crashes and restarts). Using the same steps? Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 20:02:58 Rodolfo García Peñas wrote: > Quoting Josip Deanovic : > > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > >> Solved. > >> > >> Thanks for your report. > > > > Thank you for the effort. > > > > I have just tested the code from the fresh next branch and > > the issue still exist (Windowmaker crashes and restarts). > > Using the same steps? Yes. I have even relog (not just restart) to make sure that wmaker has been completely restarted. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic : On Sunday 2015-08-23 20:02:58 Rodolfo García Peñas wrote: Quoting Josip Deanovic : > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: >> Solved. >> >> Thanks for your report. > > Thank you for the effort. > > I have just tested the code from the fresh next branch and > the issue still exist (Windowmaker crashes and restarts). Using the same steps? Yes. I have even relog (not just restart) to make sure that wmaker has been completely restarted. Thanks, I will continue with this problem tomorrow. I think I know the problem, but I need do a deep analysis. Regards, kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 20:17:08 Rodolfo García Peñas wrote: > Thanks, > > I will continue with this problem tomorrow. I think I know the > problem, but I need do a deep analysis. Ok, thank you. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.7-3-g0b5de80
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project wmaker-crm.git.
The branch, next has been updated
via 0b5de80e20ec81ce00f6d7ede5f894ea13929163 (commit)
from 7e42fedcbb25cdee72e937c99f6595f610e16c36 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://repo.or.cz/w/wmaker-crm.git/commit/0b5de80e20ec81ce00f6d7ede5f894ea13929163
commit 0b5de80e20ec81ce00f6d7ede5f894ea13929163
Author: Rodolfo García Peñas (kix)
Date: Sun Aug 23 17:33:38 2015 +0200
create_appicon_from_dock checks if no_appicon flag is set
As Josip Deanovic reported:
---8<---
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
---8<---
This patch reverts this change (not the patch). Now the function
create_appicon_from_dock checks if the flag no_appicon is set,
and then, do not execute the code related to the appicon.
Signed-off-by: Rodolfo García Peñas (kix)
diff --git a/src/appicon.c b/src/appicon.c
index 302066d..08331c7 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -1180,7 +1180,7 @@ static void create_appicon_from_dock(WWindow *wwin,
WApplication *wapp, Window m
}
/* If created, then set some flags */
- if (wapp->app_icon) {
+ if (wapp->app_icon && !WFLAGP(wapp->main_window_desc, no_appicon)) {
WWindow *mainw = wapp->main_window_desc;
wapp->app_icon->running = 1;
---
Summary of changes:
src/appicon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
repo.or.cz automatic notification. Contact project admin crma...@gmail.com
if you want to unsubscribe, or site admin ad...@repo.or.cz if you receive
no reply.
--
wmaker-crm.git ("The Window Maker window manager")
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sun, 23 Aug 2015 at 21:28:02 +0200, Josip Deanovic wrote: > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > > Solved. > > > > Thanks for your report. > > Thank you for the effort. > > I have just tested the code from the fresh next branch and > the issue still exist (Windowmaker crashes and restarts). But the #next branch doesn't contain Rodolfo's patches yet. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 22:06:30 Carlos R. Mafra wrote: > On Sun, 23 Aug 2015 at 21:28:02 +0200, Josip Deanovic wrote: > > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > > > Solved. > > > > > > Thanks for your report. > > > > Thank you for the effort. > > > > I have just tested the code from the fresh next branch and > > the issue still exist (Windowmaker crashes and restarts). > > But the #next branch doesn't contain Rodolfo's patches yet. He, he, that might be the source of the problem. :-) Ok, where can I get the newest change? I didn't notice any patch attached. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.7-9-g7a2eb68
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project wmaker-crm.git.
The branch, next has been updated
discards 0b5de80e20ec81ce00f6d7ede5f894ea13929163 (commit)
via 7a2eb68aa47a35eede44457db5d300719be4dcdd (commit)
via 8a822004eef716d3a154a78960773d52d9cc8253 (commit)
via 54db8d6c43e23ec0404875a7e2d0a1454659bd9a (commit)
via e11800652ea226528088bcbfd74677fce233600e (commit)
via b2c507898764bf33abc017675dda44ae31533812 (commit)
via 9c4b19d8aaee2f80f03853e62c753298edf12ceb (commit)
via b2815873977e364d3fd8f27b4dae82c37a23bad6 (commit)
This update added new revisions after undoing existing revisions. That is
to say, the old revision is not a strict subset of the new revision. This
situation occurs when you --force push a change and generate a repository
containing something like this:
* -- * -- B -- O -- O -- O (0b5de80e20ec81ce00f6d7ede5f894ea13929163)
\
N -- N -- N (7a2eb68aa47a35eede44457db5d300719be4dcdd)
When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://repo.or.cz/w/wmaker-crm.git/commit/7a2eb68aa47a35eede44457db5d300719be4dcdd
commit 7a2eb68aa47a35eede44457db5d300719be4dcdd
Author: Rodolfo García Peñas (kix)
Date: Sun Aug 23 20:56:59 2015 +0200
Remove cache icon when detached
This pach removes the icon from the icon cache when the icon is
detached from the dock/clip.
That helps to hold tidy the icon cache folder.
---8<---
Also app icon caching was broken around the same time. The app icon cache
in CachedPixmaps was meant to store icons retrieved from X clients so the
dock or clip can display those when the client is not running like after
startup. The cache should contain only such icons and the path should never
appear in WMWindowAttributes because the cache is an internal thing used to
look up icons not otherwise available. If you look at your
WMWindowAttributes
now it is full of entries referring to the cache that should not be there
and
if you look at the cache dir you'll find a lot of icons from all apps you've
ever started while there should be only the few docked ones that use client
side icons. Also the cache is never cleaned up only new icons are added to
it.
---8<---
Signed-off-by: Rodolfo García Peñas (kix)
diff --git a/src/dock.c b/src/dock.c
index e27b28a..3b3313b 100644
--- a/src/dock.c
+++ b/src/dock.c
@@ -2425,6 +2425,9 @@ void wDockDetach(WDock *dock, WAppIcon *icon)
dock->icon_count--;
+ /* Remove the Cached Icon */
+ remove_cache_icon(icon->icon->file);
+
/* if the dock is not attached to an application or
* the application did not set the appropriate hints yet,
* destroy the icon */
@@ -2452,6 +2455,7 @@ void wDockDetach(WDock *dock, WAppIcon *icon)
if (wPreferences.auto_arrange_icons)
wArrangeIcons(dock->screen_ptr, True);
}
+
if (dock->auto_collapse || dock->auto_raise_lower)
clipLeave(dock);
}
diff --git a/src/icon.c b/src/icon.c
index d53f756..0dbd6ac 100644
--- a/src/icon.c
+++ b/src/icon.c
@@ -529,6 +529,24 @@ char *wIconStore(WIcon *icon)
return filename;
}
+void remove_cache_icon(char *filename)
+{
+ char *cachepath;
+
+ if (!filename)
+ return;
+
+ cachepath = get_icon_cache_path();
+ if (!cachepath)
+ return;
+
+ /* Filename check/parse could be here */
+ if (!strncmp(filename, cachepath, strlen(cachepath)))
+ unlink(filename);
+
+ wfree(cachepath);
+}
+
static void cycleColor(void *data)
{
WIcon *icon = (WIcon *) data;
diff --git a/src/icon.h b/src/icon.h
index dbcb289..cccd7a8 100644
--- a/src/icon.h
+++ b/src/icon.h
@@ -80,4 +80,5 @@ void wIconSetHighlited(WIcon *icon, Bool flag);
void set_icon_image_from_image(WIcon *icon, RImage *image);
void set_icon_minipreview(WIcon *icon, RImage *image);
+void remove_cache_icon(char *filename);
#endif /* WMICON_H_ */
http://repo.or.cz/w/wmaker-crm.git/commit/8a822004eef716d3a154a78960773d52d9cc8253
commit 8a822004eef716d3a154a78960773d52d9cc8253
Author: Rodolfo García Peñas (kix)
Date: Sun Aug 23 20:56:58 2015 +0200
save the icon filename instead the full path
This patch saves the icon filename in the database and in the disk. wmaker
can find the icon in the different folders, including the cache folder.
This patc
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sun, 23 Aug 2015 at 23:09:59 +0200, Josip Deanovic wrote: > On Sunday 2015-08-23 22:06:30 Carlos R. Mafra wrote: > > On Sun, 23 Aug 2015 at 21:28:02 +0200, Josip Deanovic wrote: > > > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: > > > > Solved. > > > > > > > > Thanks for your report. > > > > > > Thank you for the effort. > > > > > > I have just tested the code from the fresh next branch and > > > the issue still exist (Windowmaker crashes and restarts). > > > > But the #next branch doesn't contain Rodolfo's patches yet. > > He, he, that might be the source of the problem. :-) > > Ok, where can I get the newest change? I didn't notice any patch attached. It is there now. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: > > Ok, where can I get the newest change? I didn't notice any patch > > attached. > It is there now. Ok, I'll test it now. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: > It is there now. I have compiled a newest version and tested every combination I could think of and works fine. No crash any more, feature works as expected. I would say that we can close this case. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
On Sun, 23 Aug 2015 at 23:38:08 +0200, Josip Deanovic wrote: > On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: > > It is there now. > > I have compiled a newest version and tested every combination I could > think of and works fine. > > No crash any more, feature works as expected. > > I would say that we can close this case. Great, thanks to both of you. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 2/3] wmload: Fix -Wunused-result compiler warning.
Obtained from the Debian package [1].
[1]
https://sources.debian.net/src/wmload/0.9.6-1/debian/patches/fix_unused_result.patch/
---
wmload/wmload.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/wmload/wmload.c b/wmload/wmload.c
index c30f7bf..eeab18b 100644
--- a/wmload/wmload.c
+++ b/wmload/wmload.c
@@ -145,7 +145,9 @@ void ExecuteExternal()
ruid = getuid();
euid = geteuid();
if ( ruid == euid ) {
- system( Execute );
+ if (system( Execute ) == -1)
+ fprintf(stderr, "system(%s) returned an error",
+ Execute);
return;
}
pid = fork();
@@ -171,7 +173,8 @@ void ExecuteExternal()
strerror(errno));
exit(127);
}
- system( Execute );
+ if (system( Execute ) == -1)
+ fprintf(stderr, "system(%s) returned an error", Execute);
exit(0);
}
int main(int argc,char *argv[])
--
2.1.4
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 3/3] wmload: Bump to version 0.9.7.
--- wmload/ChangeLog | 18 ++ wmload/wmload.c | 2 +- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/wmload/ChangeLog b/wmload/ChangeLog index 24872a2..c2e455f 100644 --- a/wmload/ChangeLog +++ b/wmload/ChangeLog @@ -1,3 +1,21 @@ +VERSION: 0.9.7 +RELEASE DATE: 23 August 2015 + -Bump _POSIX_C_SOURCE to 200112L. Otherwise, we get the following +warning during build. + wmload.c: In function ‘GetLoad’: + wmload.c:523:10: warning: incompatible implicit declaration of + built-in function ‘rint’ + *usr = rint(Maximum * (float)(*usr) /total); +^ +Obtained from the Debian package [1]. + -Fix -Wunused-result compiler warning. Obtained from the Debian +package [2]. + + [1] https://sources.debian.net/src/wmload/0.9.6-1/debian/patches/ + bump_POSIX_C_SOURCE.patch/ + [2] https://sources.debian.net/src/wmload/0.9.6-1/debian/patches/ + fix_unused_result.patch/ + VERSION: 0.9.6 RELEASE DATE: 15 April 2015 -Clarify copyright information. diff --git a/wmload/wmload.c b/wmload/wmload.c index eeab18b..b3c2427 100644 --- a/wmload/wmload.c +++ b/wmload/wmload.c @@ -42,7 +42,7 @@ #define major_VER 0 #define minor_VER 9 -#define patch_VER 6 +#define patch_VER 7 #define MW_EVENTS (ExposureMask | ButtonPressMask | StructureNotifyMask) #define FALSE 0 #define Shape(num) (ONLYSHAPE ? num-5 : num) -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 1/3] wmload: Bump _POSIX_C_SOURCE to 200112L.
Otherwise, we get the following warning during build. wmload.c: In function ‘GetLoad’: wmload.c:523:10: warning: incompatible implicit declaration of built-in function ‘rint’ *usr = rint(Maximum * (float)(*usr) /total); ^ Obtained from the Debian package [1]. [1] https://sources.debian.net/src/wmload/0.9.6-1/debian/patches/bump_POSIX_C_SOURCE.patch/ --- wmload/wmload.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wmload/wmload.c b/wmload/wmload.c index a6f55c8..c30f7bf 100644 --- a/wmload/wmload.c +++ b/wmload/wmload.c @@ -18,7 +18,7 @@ * with this program; if not, write to the Free Software Foundation, Inc., * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */ -#define _POSIX_C_SOURCE 199309L +#define _POSIX_C_SOURCE 200112L #include #include -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 0/3] wmload
Here are a few patches for wmload. Carlos, could you tag the last commit wmload-0.9.7? Thanks! Doug Torrance (3): wmload: Bump _POSIX_C_SOURCE to 200112L. wmload: Fix -Wunused-result compiler warning. wmload: Bump to version 0.9.7. wmload/ChangeLog | 18 ++ wmload/wmload.c | 11 +++ 2 files changed, 25 insertions(+), 4 deletions(-) -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 1/2] wmbattery: Add config.h.in to `make distclean`.
Its absence created a problem for the Debian package. During the build, dh_auto_clean results in a call to autoheader, which creates config.h.in. If this isn't then removed, we get a dpkg-source error. Obtained from [1]. [1] https://sources.debian.net/src/wmbattery/2.48-1/debian/patches/clean_config.h.in.patch/ --- wmbattery/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/wmbattery/Makefile b/wmbattery/Makefile index a789c50..864e1c8 100644 --- a/wmbattery/Makefile +++ b/wmbattery/Makefile @@ -6,7 +6,8 @@ clean: rm -f wmbattery *.o distclean: clean - rm -f config.status config.cache config.log makeinfo config.h configure + rm -f config.status config.cache config.log makeinfo config.h \ + config.h.in configure install: all $(INSTALL) -d $(DESTDIR)$(bindir) $(DESTDIR)$(man1dir) $(DESTDIR)$(icondir) -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 0/2] wmbattery
Here are a couple patches for wmbattery. Carlos, could you tag the last commit wmbattery-2.49? Thanks! Doug Torrance (2): wmbattery: Add config.h.in to `make distclean`. wmbattery: Bump to version 2.49. wmbattery/ChangeLog| 9 + wmbattery/Makefile | 3 ++- wmbattery/configure.ac | 2 +- 3 files changed, 12 insertions(+), 2 deletions(-) -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 2/2] wmbattery: Bump to version 2.49.
--- wmbattery/ChangeLog| 9 + wmbattery/configure.ac | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/wmbattery/ChangeLog b/wmbattery/ChangeLog index 5506dcb..852d10d 100644 --- a/wmbattery/ChangeLog +++ b/wmbattery/ChangeLog @@ -1,3 +1,12 @@ +wmbattery (2.49) + * Add config.h.in to `make distclean`. Its absence created a problem for the +Debian package. During the build, dh_auto_clean results in a call to +autoheader, which creates config.h.in. If this isn't then removed, we get +a dpkg-source error. Obtained from [1]. + + [1] https://sources.debian.net/src/wmbattery/2.48-1/debian/patches/ + clean_config.h.in.patch/ + wmbattery (2.48) * Escape hyphen in manpage. Fixes hyphen-used-as-minus-sign Lintian warning in the Debian package. Patch from [1]. diff --git a/wmbattery/configure.ac b/wmbattery/configure.ac index 8673139..6d4f2e1 100644 --- a/wmbattery/configure.ac +++ b/wmbattery/configure.ac @@ -1,5 +1,5 @@ dnl Process this file with autoconf to produce a configure script. -AC_INIT(wmbattery.c, 2.48) +AC_INIT(wmbattery.c, 2.49) AC_CONFIG_HEADER(config.h) AC_CONFIG_AUX_DIR(autoconf) -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 0/2] wmtime
Here are a couple patches for wmtime. Carlos, could you tag the last commit wmtime-1.4? Thanks! Doug Torrance (2): wmtime: Add note about libdockapp to INSTALL. wmtime: Bump to version 1.4. wmtime/CHANGES | 5 + wmtime/INSTALL | 4 +++- wmtime/wmtime.c | 2 +- 3 files changed, 9 insertions(+), 2 deletions(-) -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 1/2] wmtime: Add note about libdockapp to INSTALL.
--- wmtime/INSTALL | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/wmtime/INSTALL b/wmtime/INSTALL index 0573be5..1b206bb 100644 --- a/wmtime/INSTALL +++ b/wmtime/INSTALL @@ -2,7 +2,9 @@ Installation instructions for WMTime. Requirements -- -Nothing particular, but a computer might come in handy doh ;-) +Make sure libdockapp (at least version 0.7.0) is installed. It +may be obtained at +http://windowmaker.org/dockapps/?name=libdockapp Installation -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 2/2] wmtime: Bump to version 1.4.
--- wmtime/CHANGES | 5 + wmtime/wmtime.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/wmtime/CHANGES b/wmtime/CHANGES index d4079c4..6a3641d 100644 --- a/wmtime/CHANGES +++ b/wmtime/CHANGES @@ -3,6 +3,11 @@ WMTime changes. Version Description -- +1.4- Released 150824 + - The dockapp wmtime uses the new version of libdockapp and do + not use libwmgeneral. + - Add note about libdockapp to INSTALL. + 1.3- Released 150525 - Update to latest version of wmgeneral library. - Fix typos. Ran `codespell -w`. diff --git a/wmtime/wmtime.c b/wmtime/wmtime.c index 406c2da..70f7cad 100644 --- a/wmtime/wmtime.c +++ b/wmtime/wmtime.c @@ -103,7 +103,7 @@ const char* default_left_action = NULL; const char* default_middle_action = NULL; const char* default_right_action = NULL; -#define WMTIME_VERSION "1.3" +#define WMTIME_VERSION "1.4" // /* Global Variables */ -- 2.1.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic : On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: It is there now. I have compiled a newest version and tested every combination I could think of and works fine. No crash any more, feature works as expected. I would say that we can close this case. Thanks Josip, Regards, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Quoting BALATON Zoltan : On Sat, 22 Aug 2015, Josip Deanovic wrote: On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: Which feature was removed that you are missing? The one I am talking for over a year now. :-) Also app icon caching was broken around the same time. The app icon cache in CachedPixmaps was meant to store icons retrieved from X clients so the dock or clip can display those when the client is not running like after startup. The cache should contain only such icons and the path should never appear in WMWindowAttributes because the cache is an internal thing used to look up icons not otherwise available. If you look at your WMWindowAttributes now it is full of entries referring to the cache that should not be there and if you look at the cache dir you'll find a lot of icons from all apps you've ever started while there should be only the few docked ones that use client side icons. Also the cache is never cleaned up only new icons are added to it. Hello, Yesterday I sent some patches to solve these problems. Could you try them? The icon handling code was a bit complicated before but worked (maybe cache cleanup was broken before) until overzealous simplification attempts have messed it up so much that it is now difficult to untangle. Even more so because the object oriented design was also messed up by renaming and moving methods around so now it is not clear what object methods these functions were meant to be. I think the principles to follow should be: 1. K.I.S.S. 2. If ain't broke don't fix it. 3. If you don't understand it don't touch it. (That is, think about all possible implications of your proposed change because it may work with your particular settings but a lot of things can be set by preferences.) I agree with you. But some things in windowmaker are not clear. Some code is old and/or unused. Most of my patches are related to K.I.S.S. and remove unused code. Removing usermenu and appmenu is because IMO, these menus are not used, but I am not sure (Is easy to find if one person is using it, but very difficult to kwow if nobody is using these menus). IMO we could remove these menus because: 1. Are not documented. The user don't know how to create/use the menu. 2. Are not examples, only in the source code we can find how to configure the menu. 3. The line to show the menu (in the source) is difficult to reach by the user. Cheers, kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
