wmbutton
Hi, I am sending the wmbutton dockapp. This is the latest version that I found (0.6) (patch no 1), and then I apply some patches from Debian (thanks to Christian Aichinger (Greek0)), some of them with modifications. Other patches are new. I split the modifications to better understanding. The final version is not the Debian version, is the original version with patches. Debian version has different images and different configuration file. Debian files are not included. Probably, new icons should be included, because some of them are old (Netscape?). Patches: 1. Original version 2. Changed the patch for X11 (X11R6 is not longer used). Based on Christian patch. 3. .wmbutton renamed to sample.wmbutton. Based on Christian, but I use only this file for the user configuration and global configuration 4. Support for global configuration file. Christian patch. 5. Version simplification. Based on Christian, but the old variables are removed. 6. Better Makefile. Christian patch. 7. Code clean in wmbutton.c. I did a full code clean. 8. Added the manpage (Originally Debian manpage) 9. Bug with middle button 10. Code clean in wmbutton.h and wmb_libs.c 11. Removed initTooltip arguments (not used!) 12. Changed version to 0.7.0 Cheers, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: wmpager: tooltip or not tooltip?
On 21/08/12 13:53, Alexey I. Froloff wrote: Hi, Current version of wmpager is incompatible with Freedesktop specification. I have patches for that. But there's another issue - tooltips. Desktop names now are encoded as utf-8 strings, one does not simply use XDrawString(3X) to render utf-8 strings. This code needs to be ported to libXft or something like that. On the other hand, these tooltips conflicts with some of wmaker's show balloon for... options. Do you mind if I throw away tooltip support from wmpager completely? I have the same problem with wmbutton (see the patches). Tooltips don't support UTF-8 characters and don't check the wmaker's preferences. IMO, is better have a wmpager (with or without tooltips) than don't have nothing. Perhaps, you can hold the tooltips without utf-8 in the pager. Finally, I was thinking some days ago about dockapps. Some code is the same in many dockapps, for example CPU/memory/disk monitors checking the /proc. Now we have the same with the tooltips (wmbutton, wmpager and probably others). Probably we should think about something like libdockapps, a shared library with shared code used in dockapps. Cheers, kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: wmbutton
On 21/08/2012 21:49, Carlos R. Mafra wrote: On Tue, 21 Aug 2012 at 20:38:29 +0100, Carlos R. Mafra wrote: On Tue, 21 Aug 2012 at 21:03:19 +0200, Rodolfo kix Garcia wrote: Hi, I am sending the wmbutton dockapp. This is the latest version that I found (0.6) (patch no 1), and then I apply some patches from Debian (thanks to Christian Aichinger (Greek0)), some of them with modifications. Other patches are new. I split the modifications to better understanding. The final version is not the Debian version, is the original version with patches. Debian version has different images and different configuration file. Debian files are not included. Probably, new icons should be included, because some of them are old (Netscape?). Patches: 1. Original version 2. Changed the patch for X11 (X11R6 is not longer used). Based on Christian patch. 3. .wmbutton renamed to sample.wmbutton. Based on Christian, but I use only this file for the user configuration and global configuration 4. Support for global configuration file. Christian patch. 5. Version simplification. Based on Christian, but the old variables are removed. 6. Better Makefile. Christian patch. 7. Code clean in wmbutton.c. I did a full code clean. 8. Added the manpage (Originally Debian manpage) 9. Bug with middle button 10. Code clean in wmbutton.h and wmb_libs.c 11. Removed initTooltip arguments (not used!) 12. Changed version to 0.7.0 Good, thanks a lot. But you should have written the based on Christian note on the commit message, where it won't be lost in history. I'll ammend the logs of patches 2,3,4,5 and 6 to include the sentence: Based on Christian Aichinger patch. Ok, only patches 2 and 3 miss the sentence. I concluded too early that all the patches were missing it after seeing #2 and #3. Sorry. Thanks Carlos for upload it. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: AppIcons on clip
On 31/03/2012 18:13, Renan Traba wrote: Do you have more info? I can move the applications on clip and on dock without problems. You have the problem with the applications closed, open, both,... please, test it to get more info. only the icons on clip have this behavior, they move individually , on dock they move as one, this behavior do not differ if the icon is a dock app or is only a icon, opened or closed, I will try to take a screenshoot, but my computer with wmaker is in university and this is not my computer... Hi, I still have this mail in my Inbox. More news? Can you try it with the latest wmaker at git? Thanks, kix Thanks a lot. kix -- Renan Vedovato Traba Aluno de Bacharelado em Ciência da Computação pela Universidade Federal do Paraná Linux Register n°: 525911 -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Bug#668081: ITP: wmcore -- a dockapp that shows the usage of each core in the system.
On 08/04/2012 19:55, bitman wrote: Package: wnpp Severity: wishlist Owner: bitman bit...@bitmania.de * Package name: wmcore Version : 0.0.2 Upstream Author : bitman bit...@bitmania.de * URL : http://www.bitmania.de * License : GPL Programming Lang: C Description : a dockapp that shows the usage of each core in the system. The dockapp splits into two displays, the upper one showing the common usage of the system and the lower display showing one graph per each core. It detects the number of cores and computes the usage to be represented as a bar graph. wmcore works with a variable number of cores, the display is tested with 1 up to 16 (simulated) cores. Hi, is anybody using this dockapp? Bitman, what do you think about move your application to the dockapps repository (http://repo.or.cz/w/dockapps.git/)? Bitman, I am not using this dockapp, therefore packaging it is not good idea for me. Probably more people at wmaker-dev or wmaker-user can help you to package it. Else, if you are using debian, probably you can package this application (is easy, is a small application), I can help you. Best regards, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Grab problem
On 09/08/12 11:44, BALATON Zoltan wrote: Hello, On Wed, 8 Aug 2012, Rodolfo García Peñas wrote: Before trying to solve the problem,... we need select windows? What's the purpose of select windows? I don't use it, but probably I am missing something :-? Thanks BALATON for your reply. Never used it either but I can imagine it may be a useful feature for someone. The idea is that you can select some windows (or miniwindows) This is one of my questions, if somebody is using this feature and if this feature could be removed. and then apply an operation to all of them at once. For example you can move them together. There are at least three ways to select windows: using the Select item in the window menu, Shift+click on the title bar or starting a drag on the root window and enclosing the windows with the rectangle. Selected windows have a white border around them. Yes. I didn't know this feature, but yesterday I was playing with it :-) Not sure if this helps or answers your question though. As for solving Yes. Thanks. it, I'm not sure if there's a way without a grab or otherwise hiding changing parts of the display, because the drawn rectangle has to be reverted and if screen content changes it's not possible. (By the way, there's a simple way to see this if you have dock apps that have some moving content e.g. wmnd or a cpu load monitor or you can start 'xclock -update 1'. These will all stop when the select rectangle is being drawn.) Maybe it could be circumvented by not drawing the rectangle but using a transparent window instead (with only a border) but it may not be easy to implement or compatible with all versions of X and the same grab also happens for example when resizing a window with the technical drawing like size display so it would not fix all cases either. So I think you could close the bug as wontfix with an explanation and advise disabling the Select Windows in Prefs if someone is annoyed by it. Thanks a lot for your suggestion. Before do it (close + wontfix) I would like to know three things: 1. If somebody is using this feature. Else, can the feature removed? 2. Don't remove the feature but set Nothing as default action for left mouse. 3. Don't do nothing and close the bug and set as wontfix Regards, kix Regards, BALATON Zoltan -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Q: Adding new dockapp to dockapps.git repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/12 12:47, Alexey I. Froloff wrote: I am willing to add wmMatrix into dockapps repository. Do I need to import untouched original sources first and then commit all my changes and cleanups, or I can just commit the result of my cleanup with all additional patches applied as a single commit? Hi Alexey, IMO, is better import the original sources and then commit your changes. Doing it in this way allow to other developers (distros,...) see that the source in the git is the original with your changes. Saludos. - -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQIPQGAAoJEHsfVJByt0kjrRMQAJWNg8DDUm0VI/rS+kqW2CxW oCRDAGPDX3cL5G7CKSjvjeJ2H/X2nv87Th0k7/2GzwvJFda4k5ccjujZAT+gU6km uBcyTa3noNOAOWxKksIX26S+Ha/YHAx2mnUSxDxlqP9pIJnnYJ+1kUmCJf4JYoIK zvpfdD024g1tRmoxsQPowVj3P7Aad/SpxEZfx900wQhJsqzwiL0ynvCJ3e7GuLXm vK4Q1bqhTOwCsMSrx8VV50E9QzXhk4GJAjS0NXfnDBm6X2JE2yV3SLdzRj0GClIJ AaMi9AdNXIs8M3JWBsyMxpuMBiaOtnjOOE+Otc6cjtoC1SZF8vGcv6S+eTpiT1pB kLha+leGi91eIKdL8Hpu16teib+BwHp8Ww3gvrrrIoZXhIimqwmCdia41hUzsyWR 470pj1eo5OePIfFfl90wv3qurzuU0Ekj84UyGF/BH20nlZEhfAlykD/D3RC/A6MZ S5EilfUxxqbc1w0dpDqWSrx8kdNK6987TM8RUuquI+kp+ZwXNJy7/FBjDPuUn3Ww tNgcOnNvNavh+ctdU22kdgXBix8TJZB+vlrAG7aiYHl83cz6Amgx07967B0I9D0Y AX2sUjU7sAjBpSHmiyEWkCbIO7X9i4SDhlI/Jqs9iZfww/SviC8tGcM+9bi9504D Ani8dBM+mox3lkr0bmUY =yMKq -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Q: Adding new dockapp to dockapps.git repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/12 12:55, Carlos R. Mafra wrote: On Tue, 7 Aug 2012 at 14:47:17 +0400, Alexey I. Froloff wrote: I am willing to add wmMatrix into dockapps repository. Do I need to import untouched original sources first and then commit all my changes and cleanups, or I can just commit the result of my cleanup with all additional patches applied as a single commit? I think you can do it in just one commit if you clearly specify in the commit log that it's not the original source. 2 mails, 2 different options. :-) - -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQIPR0AAoJEHsfVJByt0kj/DgP/1s6NEnNHK3GJwcjEdGbLmeS 2q4Us8Yi9aYZrxTsRFoK7IBZRG7RbUVWtod1uPAjlY9Q0ufsAkacWXaorkoB0oEX mWr7UkzHpF4iVzOZ1y5C+VAiAO5vwEQ4n8gVZ+nVAvfbiKXJxuA2U0539eR2UlcA YHf3efHVHPZAKJMN70WA7LK6gcHPXlqQb+fbbG9DjwUN8MQvsQC5ezGTSe9vi+Re 3nhnlj0MHDsiBrFNpkk3UWjrjaXnyyYlZVSs8So/aqGH1JvJiqlTSeq1SCtWO9gL 54wXmHmg9ducRsQaIIxixKqKM3ZTryeV+e+jVHXP1fEukM/1w9WJq16DiyrOIyKk iAxQWLzTlwdBrzLMdKfBjAmp3xDNUWW39CJS6Qt9MtAliOWniQkcy0q8THjajHlX orMXKPVE00VZz/zjvrEgeCum9OwwZRJeZ2KgY4+C3rumB9QWRt9LaMoTUaV9ZuU0 E3HJmYM2h3+0XAa6uKw7koNhVeTbB9S18VCIm4jHvNSwHZdbPQvLCZYHchY74OxJ n5Hv79j0RG/LGFkKOyQcJBbTYQ5zjrO6Xr8gFTnbJmwaRD7ulVBjhMIUmyq/OrTz GY2mjnViJ06krXQSr+YkJ0dap7i9RPwgHvC0hAer7M0jur9CCiMOHYWKLmYh/iGY tycEOjtzTGtqm9aNt2o2 =Zskw -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: DnD support
El 19.06.2012 18:09, Rodolfo kix Garcia escribió: Hi, is drag and drop safe? Is not enabled in Debian and I am trying to enable it. Thanks, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ I got a lot of comments :-) Are more people interested in join the votation? :-P -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 07/11] net_state_from_client can be removed
El 26.06.2012 01:12, Carlos R. Mafra escribió:
On Mon, 25 Jun 2012 at 23:48:51 +0200, Rodolfo García Peñas wrote:
Subject: [PATCH 07/11] net_state_from_client can be removed
The variable net_state_from_client don't change their value in the
code, therefore, we don't need check it in any if.
---
src/window.h |1 -
src/wmspec.c |4 +---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/window.h b/src/window.h
index e2d516a..ae1e704 100644
--- a/src/window.h
+++ b/src/window.h
@@ -290,7 +290,6 @@ typedef struct WWindow {
unsigned int user_changed_width:1;
unsigned int user_changed_height:1;
-unsigned int net_state_from_client:1; /* state hint was set
by client */
unsigned int net_skip_pager:1;
unsigned int net_handle_icon:1;
unsigned int net_show_desktop:1;
diff --git a/src/wmspec.c b/src/wmspec.c
index 9456841..ae870ea 100644
--- a/src/wmspec.c
+++ b/src/wmspec.c
@@ -795,9 +795,7 @@ static void updateWorkspaceHint(WWindow * wwin,
Bool fake, Bool del)
static void updateStateHint(WWindow * wwin, Bool changedWorkspace,
Bool del)
{ /* changeable */
if (del) {
- if (!wwin-flags.net_state_from_client) {
- XDeleteProperty(dpy, wwin-client_win, net_wm_state);
- }
+ XDeleteProperty(dpy, wwin-client_win, net_wm_state);
I don't know. I wonder if we should try to look where and when
we should set this variable.
I had the same question. Can I remove this?
net_state_from_client is defined in the struct, but never is
initalized. Then, is used in the if.
Normally, the compiler can init a value to 0 (or not!). Then, this
could be an error.
What I did? I added a printfs, something like:
if (del) {
printf(1\n);
if (!wwin-flags.net_state_from_client) {
printf(2\n);
XDeleteProperty(dpy, wwin-client_win, net_wm_state);
}
And then I runned windowmaker some time. Open windows,... I always get
1\n2\n on the screen. If I got a 1, then I got a 2. That make sense,
because the value of wwin-flags.net_state_from_client should be 0
(compiler init), then if (!0) is like true.
For this reason, I remove the if.
I any case, we should do something. Now the value depends in if the
compiler init or not the value. Do you like this code?
int main(void)
{
int a;
if (!a)
printf(No a\n);
}
The compiler will show a warning, because a is not initialized. IMO,
is the same case (I'm the compiler ;-) ).
Cheers,
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 07/11] net_state_from_client can be removed
El 26.06.2012 10:32, Rodolfo kix Garcia escribió:
El 26.06.2012 01:12, Carlos R. Mafra escribió:
On Mon, 25 Jun 2012 at 23:48:51 +0200, Rodolfo García Peñas wrote:
Subject: [PATCH 07/11] net_state_from_client can be removed
The variable net_state_from_client don't change their value in the
code, therefore, we don't need check it in any if.
---
src/window.h |1 -
src/wmspec.c |4 +---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/window.h b/src/window.h
index e2d516a..ae1e704 100644
--- a/src/window.h
+++ b/src/window.h
@@ -290,7 +290,6 @@ typedef struct WWindow {
unsigned int user_changed_width:1;
unsigned int user_changed_height:1;
-unsigned int net_state_from_client:1; /* state hint was
set by client */
unsigned int net_skip_pager:1;
unsigned int net_handle_icon:1;
unsigned int net_show_desktop:1;
diff --git a/src/wmspec.c b/src/wmspec.c
index 9456841..ae870ea 100644
--- a/src/wmspec.c
+++ b/src/wmspec.c
@@ -795,9 +795,7 @@ static void updateWorkspaceHint(WWindow * wwin,
Bool fake, Bool del)
static void updateStateHint(WWindow * wwin, Bool changedWorkspace,
Bool del)
{ /* changeable */
if (del) {
- if (!wwin-flags.net_state_from_client) {
- XDeleteProperty(dpy, wwin-client_win, net_wm_state);
- }
+ XDeleteProperty(dpy, wwin-client_win, net_wm_state);
I don't know. I wonder if we should try to look where and when
we should set this variable.
I had the same question. Can I remove this?
net_state_from_client is defined in the struct, but never is
initalized. Then, is used in the if.
Normally, the compiler can init a value to 0 (or not!). Then, this
could be an error.
What I did? I added a printfs, something like:
if (del) {
printf(1\n);
if (!wwin-flags.net_state_from_client) {
printf(2\n);
XDeleteProperty(dpy, wwin-client_win, net_wm_state);
}
And then I runned windowmaker some time. Open windows,... I always
get 1\n2\n on the screen. If I got a 1, then I got a 2. That make
sense, because the value of wwin-flags.net_state_from_client should
be 0 (compiler init), then if (!0) is like true.
For this reason, I remove the if.
I any case, we should do something. Now the value depends in if the
compiler init or not the value. Do you like this code?
int main(void)
{
int a;
if (!a)
printf(No a\n);
}
The compiler will show a warning, because a is not initialized.
IMO, is the same case (I'm the compiler ;-) ).
Cheers,
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
I know that the patch was applied, but I am trying to show why I did
that change.
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
About my last patches
Hi, I was trying to work with the header files and I found that some variables and functions are not used, only declared,... Probably more people can help with this issue. Is easy, you only need open a header file and for every function/struct/var if is used. grep is your friend here: grep variable * The compiler checks if the .c files variables are used, so you don't need check them. But, in the .c files, the functions that are not static should be used, therefore you can check the functions too with grep. If the function is used only in the file, change it to static. Now you can help with windowmaker, make your own patch :-) kix PS. I know that I could rebase some patches :-( -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
El 21.06.2012 13:29, Carlos R. Mafra escribió: On Thu, 21 Jun 2012 at 0:20:50 +0200, Rodolfo kix Garcia wrote: With the new code, the wArrangeIcon checks if wwapp-icon exists, If is null, then doesn't exists and for this reason the icon is not added in the icon list. But with my patch, always exists, therefore, wwapp-icon is always true and then the icon is added, but, the icon is not mapped in X11, then you cannot see it. Ok, you seem to have understood the problem, but your patch last night didn't fix it. Strange. I will check that again. Ok. Thanks a lot. Please, test it again and if you find a reproducible problem I can check it here and try to write a better patch. I was working in a big patch to solve the icon problems (see the 11 bugs at [1]) and the work at [2] (~19 patches for icons). This patches are a new behavior for the icon stuff, is not a small patch. For this reason, probably we should use more time to do it than a normal patch (code clean,...). Thanks Carlos, Best Regards, kix [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yessrc=wmaker [2] http://repo.or.cz/w/wmaker-crm.git/search?s=Rodolfo+Garc%C3%ADa+Pe%C3%B1as+(kix);st=author -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
El 21.06.2012 18:02, Carlos R. Mafra escribió:
On Thu, 21 Jun 2012 at 14:26:42 +0200, Rodolfo kix Garcia wrote:
El 21.06.2012 13:29, Carlos R. Mafra escribió:
On Thu, 21 Jun 2012 at 0:20:50 +0200, Rodolfo kix Garcia wrote:
With the new code, the wArrangeIcon checks if wwapp-icon
exists, If is
null, then doesn't exists and for this reason the icon is not
added in
the icon list. But with my patch, always exists, therefore,
wwapp-icon
is always true and then the icon is added, but, the icon is not
mapped
in X11, then you cannot see it.
Ok, you seem to have understood the problem, but your patch last
night
didn't fix it. Strange. I will check that again.
Ok. Thanks a lot. Please, test it again and if you find a
reproducible problem I can check it here and try to write a better
patch.
The patch below fixes it for me. It seems like the problem exists
because
as the icon is always created no matter if no_appicon is set or not,
it
is also added to the list of appicons.
So when the wArrangeIcons() is called it finds a position to place
all the appicons in that list, including the phantom no_appicons.
I have to think more about why your patch to check the no_appicon
property in wArrangeIcons() does not work though (I double checked it
this afternoon).
What do you think?
---
src/appicon.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/appicon.c b/src/appicon.c
index d236313..594721c 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -248,12 +248,17 @@ static WAppIcon *wAppIconCreate(WWindow *
leader_win)
aicon-yindex = -1;
aicon-xindex = -1;
- aicon-prev = NULL;
- aicon-next = scr-app_icon_list;
- if (scr-app_icon_list)
- scr-app_icon_list-prev = aicon;
+ /* When no_appicon is set we want to avoid having it on the list
+* because otherwise there will be a hole when the icons are
+* arranged with wArrangeIcons() */
+ if (!WFLAGP(leader_win, no_appicon)) {
+ aicon-prev = NULL;
+ aicon-next = scr-app_icon_list;
+ if (scr-app_icon_list)
+ scr-app_icon_list-prev = aicon;
- scr-app_icon_list = aicon;
+ scr-app_icon_list = aicon;
+ }
if (leader_win-wm_class)
aicon-wm_class = wstrdup(leader_win-wm_class);
--
1.7.7
Thanks,
I will try it later, but I am not sure if the patch is good. With this
patch you are not including the icon in the appicon list, and this list
is used in some places. Perhaps is correct, perhaps no. I will try it
later.
I did this patch. It works here (I found the problem again). The idea
is skip the icon from the icon list if the no_appicon flag is set (the
printf can be removed ;-)):
kix@kentin:~/src/wmaker-crm/src$ git diff
diff --git a/src/actions.c b/src/actions.c
index 61be535..1f8de9f 100644
--- a/src/actions.c
+++ b/src/actions.c
@@ -1757,8 +1757,13 @@ void wArrangeIcons(WScreen *scr, Bool
arrangeAll)
aicon = aicon-next;
while (aicon) {
- if (!aicon-docked) {
- /* CHECK: can icon be NULL here ? */
+ WApplication *wapp = NULL;
+ if (aicon aicon-icon
+ aicon-icon-owner
aicon-icon-owner-main_window)
+ wapp =
wApplicationOf(aicon-icon-owner-main_window);
+
+ if ((!aicon-docked) (wapp
WFLAGP(wapp-main_window_desc, no_appicon))) {
+ printf(Creando icono\n);
/* The intention here is to place the AppIcon
on the head that
* contains most of the applications _main_
window. */
head = wGetHeadForWindow(aicon-icon-owner);
@@ -1787,7 +1792,10 @@ void wArrangeIcons(WScreen *scr, Bool
arrangeAll)
wwin = wwin-prev;
while (wwin) {
- if (wwin-icon wwin-flags.miniaturized
!wwin-flags.hidden
+ if (wwin-icon
+ !wwin-user_flags.no_appicon
+ wwin-flags.miniaturized
+ !wwin-flags.hidden
(wwin-frame-workspace == scr-current_workspace
||
IS_OMNIPRESENT(wwin) ||
wPreferences.sticky_icons)) {
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
El 20.06.2012 15:54, Carlos R. Mafra escribió:
On Wed, 20 Jun 2012 at 15:29:10 +0200, Rodolfo kix Garcia wrote:
El 19.06.2012 18:07, Rodolfo kix Garcia escribió:
El 19.06.2012 11:24, Carlos R. Mafra escribió:
On Mon, 18 Jun 2012 at 23:11:27 +0200, Rodolfo García Peñas wrote:
Subject: [PATCH 05/12] Create WAppIcon always
When the application is created, the WAppIcon now is created
always,
but 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 is always called.
---
src/appicon.c |3 +++
src/application.c | 23 ++-
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/appicon.c b/src/appicon.c
index c19efa0..ed4403c 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -975,6 +975,9 @@ void app_icon_create_from_docks(WWindow
*wwin, WApplication *wapp, Window main_w
{
WScreen *scr = wwin-screen_ptr;
+ /* Create the application icon */
+ wapp-app_icon = NULL;
+
if (scr-last_dock)
wapp-app_icon = findDockIconFor(scr-last_dock, main_window);
diff --git a/src/application.c b/src/application.c
index be305b2..f29e90f 100644
--- a/src/application.c
+++ b/src/application.c
@@ -158,20 +158,17 @@ WApplication *wApplicationCreate(WWindow
* wwin)
/* application descriptor */
XSaveContext(dpy, main_window, wAppWinContext, (XPointer)
wapp);
- /* Create the application icon */
- wapp-app_icon = NULL;
- if (!WFLAGP(wapp-main_window_desc, no_appicon)) {
- /* Create the application icon using the icon from docks
-* If not found in docks, create a new icon
-* using the function wAppIconCreate() */
- app_icon_create_from_docks(wwin, wapp, main_window);
-
- /* Now, paint the icon */
- paint_app_icon(wapp);
+ /* Create the application icon using the icon from docks
+* If not found in docks, create a new icon
+* using the function wAppIconCreate() */
+ app_icon_create_from_docks(wwin, wapp, main_window);
- /* Save the app_icon in a file */
- save_app_icon(wwin, wapp);
- }
+ /* Save the app_icon in a file */
+ save_app_icon(wwin, wapp);
+
+ /* Now, paint the icon */
+ if (!WFLAGP(wapp-main_window_desc, no_appicon))
+ paint_app_icon(wapp);
return wapp;
}
This commit causes the regression I reported earlier, about the
appicons
being created shifted to the right on the bottom of the screen
(as if that
space was occupied by other icons).
The only odd thing here is that I have a xterm with no_appicon
set, and
that whenever I start wmaker the application xconsole is
automatically
started, but its appicon is shifted. That happens for all the
other
apps I start.
Thanks Carlos,
I will check this problem. Something in app_icon_create calls an
X11-Map function. I will check it these days.
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
Carlos,
I cannot reproduce the problem :-? Probably the bug is, of course,
but I cannot see it.
Here the things are fine. If I set the no_appicon flag, all runs
correctly.
Can you send me more info? Can you test your WMStatus file? Can you
so something with xwininfo or other x11 tools?
So I'd say the problem lies in the automatic start of applications
which have no appicon.
I have three xterms which automatically start (through the Save
Session)
and they all have no_appicon set. It seems that the space
corresponding
to three appicons is in use, and if I start some other application
then its appicon is placed in a shifted position which is equivalent
to 3 appicons.
And I bisected the problem to this commit.
I see. I start windowmaker with xterm and xconsole saved and with
no_appicon set. All is fine, and when I minimize the window, no problem.
But when I change the workspace, then the icons are shorted, and then
the left space appears.
Is the same for you? Perhaps the problem is not in the application
creation, but in other part of the code.
Thanks.
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
El 20.06.2012 16:01, Carlos R. Mafra escribió: On Wed, 20 Jun 2012 at 14:54:05 +0100, Carlos R. Mafra wrote: So I'd say the problem lies in the automatic start of applications which have no appicon. I have three xterms which automatically start (through the Save Session) and they all have no_appicon set. It seems that the space corresponding to three appicons is in use, and if I start some other application then its appicon is placed in a shifted position which is equivalent to 3 appicons. And I bisected the problem to this commit. It doesn't matter if the automatically start or not. My xterms have no appicon. After I start one, the space which would be occupied by its icon is not used by other appicons. Not here. So if I start one xterm than another app (with appicon) and so forth, the icons of the application are placed 64 pixels apart. Here interesting example. I set xfig without icon. Launch xcalc, xterm,... no problems Launch xfig. No problem with icons. Minimize the xterms,... No problem, the hole doesn't exists. Now, change the desktop. The hole appears. Can you confirm that? Do you change the desktop at startup? kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
On 20/06/12 16:01, Carlos R. Mafra wrote:
On Wed, 20 Jun 2012 at 14:54:05 +0100, Carlos R. Mafra wrote:
So I'd say the problem lies in the automatic start of applications
which have no appicon.
I have three xterms which automatically start (through the Save Session)
and they all have no_appicon set. It seems that the space corresponding
to three appicons is in use, and if I start some other application
then its appicon is placed in a shifted position which is equivalent
to 3 appicons.
And I bisected the problem to this commit.
It doesn't matter if the automatically start or not. My xterms
have no appicon. After I start one, the space which would be
occupied by its icon is not used by other appicons.
So if I start one xterm than another app (with appicon) and
so forth, the icons of the application are placed 64 pixels
apart.
I found the problem. The problem is that the wArrangeIcon function
checks if the icon exists. Now, the icon always exists, then is added
space for the appicon. The function now should check the flag:
!wwin-user_flags.no_appicon
instead wwin-icon.
Carlos, can you check it now? If is ok, I will create a patch. This code
is copy/paste in thunderbird, then the tabs are spaces, the LR/CR is
added and is a crap.
Thanks for your report.
kix.
kix@kentin:~/src/wmaker-crm/src$ git diff
diff --git a/src/actions.c b/src/actions.c
index 61be535..686350c 100644
--- a/src/actions.c
+++ b/src/actions.c
@@ -1787,7 +1787,10 @@ void wArrangeIcons(WScreen *scr, Bool arrangeAll)
wwin = wwin-prev;
while (wwin) {
- if (wwin-icon wwin-flags.miniaturized
!wwin-flags.hidden
+ if (wwin-icon
+ !wwin-user_flags.no_appicon
+ wwin-flags.miniaturized
+ !wwin-flags.hidden
(wwin-frame-workspace == scr-current_workspace ||
IS_OMNIPRESENT(wwin) || wPreferences.sticky_icons)) {
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
On 20/06/12 23:50, Carlos R. Mafra wrote:
On Wed, 20 Jun 2012 at 22:47:52 +0200, Rodolfo kix Garcia wrote:
On 20/06/12 22:12, Carlos R. Mafra wrote:
On Wed, 20 Jun 2012 at 21:17:15 +0200, Rodolfo kix Garcia wrote:
On 20/06/12 16:01, Carlos R. Mafra wrote:
On Wed, 20 Jun 2012 at 14:54:05 +0100, Carlos R. Mafra wrote:
So I'd say the problem lies in the automatic start of applications
which have no appicon.
I have three xterms which automatically start (through the Save Session)
and they all have no_appicon set. It seems that the space corresponding
to three appicons is in use, and if I start some other application
then its appicon is placed in a shifted position which is equivalent
to 3 appicons.
And I bisected the problem to this commit.
It doesn't matter if the automatically start or not. My xterms
have no appicon. After I start one, the space which would be
occupied by its icon is not used by other appicons.
So if I start one xterm than another app (with appicon) and
so forth, the icons of the application are placed 64 pixels
apart.
I found the problem. The problem is that the wArrangeIcon function
checks if the icon exists. Now, the icon always exists, then is added
space for the appicon. The function now should check the flag:
!wwin-user_flags.no_appicon
instead wwin-icon.
No, the patch does not fix it. I will revert the patch which causes
this in the first place.
Carlos,
if you want to revert the patch, do it, no problem. But IMO, here, the
patch solves the problem :-/
You are seeing some other issue then. I also noticed something strange
related to changing workspaces and rearranging icons when trying to
reproduce the bug with a clean GNUstep/
But it definitely does not solve what I'm seeing here.
Yes, the wArrangeFunction is called when the wmaker start and when you
make workspaces changes.
It does not really make sense to do work if we know that no_appicon
is set, it is a waste.
Now, the wApplicationCreate creates wapp and wapp-icon, always!
I don't understand why you are saying this. Your patch was named
Create WAppIcon always, wasn't it? What's the difference from
now? Look at the revert patch:
diff --git a/src/appicon.c b/src/appicon.c
index 6cc2bca..c77633d 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -956,9 +956,6 @@ void create_appicon_from_dock(WWindow *wwin, WApplication
*wapp, Window main_win
{
WScreen *scr = wwin-screen_ptr;
- /* Create the application icon */
- wapp-app_icon = NULL;
-
if (scr-last_dock)
wapp-app_icon = findDockIconFor(scr-last_dock, main_window);
diff --git a/src/application.c b/src/application.c
index f0122f0..c98a3e8 100644
--- a/src/application.c
+++ b/src/application.c
@@ -143,13 +143,21 @@ WApplication *wApplicationCreate(WWindow * wwin)
/* application descriptor */
XSaveContext(dpy, main_window, wAppWinContext, (XPointer) wapp);
- /* Create the application icon using the icon from docks
- * If not found in docks, create a new icon
- * using the function wAppIconCreate() */
- create_appicon_from_dock(wwin, wapp, main_window);
+ /* Create the application icon */
+ wapp-app_icon = NULL;
- /* Save the app_icon in a file */
- save_app_icon(wapp);
+ if (!WFLAGP(wapp-main_window_desc, no_appicon)) {
+ /* Create the application icon using the icon from docks
+ * If not found in docks, create a new icon
+ * using the function wAppIconCreate() */
+ create_appicon_from_dock(wwin, wapp, main_window);
+
+ /* Now, paint the icon */
+ paint_app_icon(wapp);
+
+ /* Save the app_icon in a file */
+ save_app_icon(wapp);
+ }
return wapp;
}
You were creating the icon
/* Create the application icon */
wapp-app_icon = NULL;
No! I am initializing the icon to NULL, the icon doesn't exists. If you
check it with if (wapp-app_icon) it fails.
from inside create_appicon_from_dock(), which btw was always called.
But now the work is done inside the check if no_appicon is set, and
that makes a lot of sense to me.
No, create_appicon_from_dock() is called if no_appicon is not set. If is
set, the icon doesn't exists, and continue with NULL.
Then, the checks about if (wwin-icon) don't make sense.
?
Yes! :-) if (wwin-icon) is NULL, we don't enter in the if. But in
wArrangeIcon, with my patch, always exists, and we need check if the
flag no_appicon is set.
If the icon is created always, we don't need check if exists, we don't
need create the icon or destroy,... the code is more easy, we need less
code, and IMO better.
I'm not following you. I just moved the
create_appicon_from_dock()
paint_app_icon()
save_app_icon()
to inside the no_appicon check.
The wapp-app_icon = NULL is being always set, with or without the
revert patch
Re: [PATCH 05/12] Create WAppIcon always
On 21/06/12 00:20, Rodolfo kix Garcia wrote:
On 20/06/12 23:50, Carlos R. Mafra wrote:
On Wed, 20 Jun 2012 at 22:47:52 +0200, Rodolfo kix Garcia wrote:
On 20/06/12 22:12, Carlos R. Mafra wrote:
On Wed, 20 Jun 2012 at 21:17:15 +0200, Rodolfo kix Garcia wrote:
On 20/06/12 16:01, Carlos R. Mafra wrote:
On Wed, 20 Jun 2012 at 14:54:05 +0100, Carlos R. Mafra wrote:
So I'd say the problem lies in the automatic start of applications
which have no appicon.
I have three xterms which automatically start (through the Save Session)
and they all have no_appicon set. It seems that the space corresponding
to three appicons is in use, and if I start some other application
then its appicon is placed in a shifted position which is equivalent
to 3 appicons.
And I bisected the problem to this commit.
It doesn't matter if the automatically start or not. My xterms
have no appicon. After I start one, the space which would be
occupied by its icon is not used by other appicons.
So if I start one xterm than another app (with appicon) and
so forth, the icons of the application are placed 64 pixels
apart.
I found the problem. The problem is that the wArrangeIcon function
checks if the icon exists. Now, the icon always exists, then is added
space for the appicon. The function now should check the flag:
!wwin-user_flags.no_appicon
instead wwin-icon.
No, the patch does not fix it. I will revert the patch which causes
this in the first place.
Carlos,
if you want to revert the patch, do it, no problem. But IMO, here, the
patch solves the problem :-/
You are seeing some other issue then. I also noticed something strange
related to changing workspaces and rearranging icons when trying to
reproduce the bug with a clean GNUstep/
But it definitely does not solve what I'm seeing here.
Yes, the wArrangeFunction is called when the wmaker start and when you
make workspaces changes.
It does not really make sense to do work if we know that no_appicon
is set, it is a waste.
Now, the wApplicationCreate creates wapp and wapp-icon, always!
I don't understand why you are saying this. Your patch was named
Create WAppIcon always, wasn't it? What's the difference from
now? Look at the revert patch:
diff --git a/src/appicon.c b/src/appicon.c
index 6cc2bca..c77633d 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -956,9 +956,6 @@ void create_appicon_from_dock(WWindow *wwin,
WApplication *wapp, Window main_win
{
WScreen *scr = wwin-screen_ptr;
-/* Create the application icon */
-wapp-app_icon = NULL;
-
if (scr-last_dock)
wapp-app_icon = findDockIconFor(scr-last_dock, main_window);
diff --git a/src/application.c b/src/application.c
index f0122f0..c98a3e8 100644
--- a/src/application.c
+++ b/src/application.c
@@ -143,13 +143,21 @@ WApplication *wApplicationCreate(WWindow * wwin)
/* application descriptor */
XSaveContext(dpy, main_window, wAppWinContext, (XPointer) wapp);
-/* Create the application icon using the icon from docks
- * If not found in docks, create a new icon
- * using the function wAppIconCreate() */
-create_appicon_from_dock(wwin, wapp, main_window);
+/* Create the application icon */
+wapp-app_icon = NULL;
-/* Save the app_icon in a file */
-save_app_icon(wapp);
+if (!WFLAGP(wapp-main_window_desc, no_appicon)) {
+/* Create the application icon using the icon from docks
+ * If not found in docks, create a new icon
+ * using the function wAppIconCreate() */
+create_appicon_from_dock(wwin, wapp, main_window);
+
+/* Now, paint the icon */
+paint_app_icon(wapp);
+
+/* Save the app_icon in a file */
+save_app_icon(wapp);
+}
return wapp;
}
You were creating the icon
/* Create the application icon */
wapp-app_icon = NULL;
No! I am initializing the icon to NULL, the icon doesn't exists. If you
check it with if (wapp-app_icon) it fails.
from inside create_appicon_from_dock(), which btw was always called.
But now the work is done inside the check if no_appicon is set, and
that makes a lot of sense to me.
No, create_appicon_from_dock() is called if no_appicon is not set. If is
set, the icon doesn't exists, and continue with NULL.
Then, the checks about if (wwin-icon) don't make sense.
?
Yes! :-) if (wwin-icon) is NULL, we don't enter in the if. But in
wArrangeIcon, with my patch, always exists, and we need check if the
flag no_appicon is set.
If the icon is created always, we don't need check if exists, we don't
need create the icon or destroy,... the code is more easy, we need less
code, and IMO better.
I'm not following you. I just moved the
create_appicon_from_dock()
paint_app_icon()
save_app_icon()
to inside the no_appicon check.
The wapp-app_icon = NULL is being always set
Re: Re : Next patches - patch ideas
El 19.06.2012 09:55, Christophe escribió: - Rodolfo García Peñas k...@kix.es a écrit : Hi, [...] The menu could be better. First, probably we should remove the gcc, using an small functions (see other mails in the mail list about it). [...] Hi, I'm currently working on a patch for this, for which the code is ready but I'm working on making the patch looking clean. It is likely to come by the end of the week. Great! I would like remove the gcc depend in debian/control file :-) I was also considering adding native support for XDG Menus, but that's another story for later. Yes, IMO probably move to XDG is good [1]. Is an standard, we can use other tools to configure it, is used by other wm,... If I remember, OpenSuse is using xdg for the menu generation (but I am not sure). But the change is bigger. Regards, Christophe. [1] http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
El 19.06.2012 11:24, Carlos R. Mafra escribió:
On Mon, 18 Jun 2012 at 23:11:27 +0200, Rodolfo García Peñas wrote:
Subject: [PATCH 05/12] Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but 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 is always called.
---
src/appicon.c |3 +++
src/application.c | 23 ++-
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/appicon.c b/src/appicon.c
index c19efa0..ed4403c 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -975,6 +975,9 @@ void app_icon_create_from_docks(WWindow *wwin,
WApplication *wapp, Window main_w
{
WScreen *scr = wwin-screen_ptr;
+ /* Create the application icon */
+ wapp-app_icon = NULL;
+
if (scr-last_dock)
wapp-app_icon = findDockIconFor(scr-last_dock, main_window);
diff --git a/src/application.c b/src/application.c
index be305b2..f29e90f 100644
--- a/src/application.c
+++ b/src/application.c
@@ -158,20 +158,17 @@ WApplication *wApplicationCreate(WWindow *
wwin)
/* application descriptor */
XSaveContext(dpy, main_window, wAppWinContext, (XPointer) wapp);
- /* Create the application icon */
- wapp-app_icon = NULL;
- if (!WFLAGP(wapp-main_window_desc, no_appicon)) {
- /* Create the application icon using the icon from docks
-* If not found in docks, create a new icon
-* using the function wAppIconCreate() */
- app_icon_create_from_docks(wwin, wapp, main_window);
-
- /* Now, paint the icon */
- paint_app_icon(wapp);
+ /* Create the application icon using the icon from docks
+* If not found in docks, create a new icon
+* using the function wAppIconCreate() */
+ app_icon_create_from_docks(wwin, wapp, main_window);
- /* Save the app_icon in a file */
- save_app_icon(wwin, wapp);
- }
+ /* Save the app_icon in a file */
+ save_app_icon(wwin, wapp);
+
+ /* Now, paint the icon */
+ if (!WFLAGP(wapp-main_window_desc, no_appicon))
+ paint_app_icon(wapp);
return wapp;
}
This commit causes the regression I reported earlier, about the
appicons
being created shifted to the right on the bottom of the screen (as if
that
space was occupied by other icons).
The only odd thing here is that I have a xterm with no_appicon set,
and
that whenever I start wmaker the application xconsole is
automatically
started, but its appicon is shifted. That happens for all the other
apps I start.
Thanks Carlos,
I will check this problem. Something in app_icon_create calls an
X11-Map function. I will check it these days.
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
DnD support
Hi, is drag and drop safe? Is not enabled in Debian and I am trying to enable it. Thanks, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
On 19/06/12 00:05, Carlos R. Mafra wrote:
On Mon, 18 Jun 2012 at 23:11:27 +0200, Rodolfo García Peñas wrote:
Subject: [PATCH 05/12] Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but 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 is always called.
---
src/appicon.c |3 +++
src/application.c | 23 ++-
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/appicon.c b/src/appicon.c
index c19efa0..ed4403c 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -975,6 +975,9 @@ void app_icon_create_from_docks(WWindow *wwin,
WApplication *wapp, Window main_w
{
WScreen *scr = wwin-screen_ptr;
+/* Create the application icon */
+wapp-app_icon = NULL;
+
if (scr-last_dock)
wapp-app_icon = findDockIconFor(scr-last_dock, main_window);
diff --git a/src/application.c b/src/application.c
index be305b2..f29e90f 100644
--- a/src/application.c
+++ b/src/application.c
@@ -158,20 +158,17 @@ WApplication *wApplicationCreate(WWindow * wwin)
/* application descriptor */
XSaveContext(dpy, main_window, wAppWinContext, (XPointer) wapp);
-/* Create the application icon */
-wapp-app_icon = NULL;
-if (!WFLAGP(wapp-main_window_desc, no_appicon)) {
-/* Create the application icon using the icon from docks
- * If not found in docks, create a new icon
- * using the function wAppIconCreate() */
-app_icon_create_from_docks(wwin, wapp, main_window);
-
-/* Now, paint the icon */
-paint_app_icon(wapp);
+/* Create the application icon using the icon from docks
+ * If not found in docks, create a new icon
+ * using the function wAppIconCreate() */
+app_icon_create_from_docks(wwin, wapp, main_window);
It's just a small detail, but I think it is more natural to create the
appicon calling a function named wAppIconCreate() instead of calling
app_icon_create_from_docks() which ultimately calls wAppIconCreate()
if the icon is not found in the dock.
Yes. Probably the name of app_icon_create_from_docks is incorrect, but
I think is better have the code in this function and outside of the
wApplicationCreate function. Now the application creation is more clear.
And, yes, the name is better wAppIconCreate. But the code in this
function is like the code in wAppIconCreateForDock. I tried join both
functions, but I leave it (time).
I will think about it.
Perhaps the function app_icon_create_from_docks() should be called
from wAppIconCreate() and not the reverse. I will apply this patch,
but I thought I should raise this question here anyway for a possible
further streamlining.
-/* Save the app_icon in a file */
-save_app_icon(wwin, wapp);
-}
+/* Save the app_icon in a file */
+save_app_icon(wwin, wapp);
+
+/* Now, paint the icon */
+if (!WFLAGP(wapp-main_window_desc, no_appicon))
+paint_app_icon(wapp);
return wapp;
}
--
1.7.10
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 05/12] Create WAppIcon always
On 19/06/12 00:45, Carlos R. Mafra wrote:
On Tue, 19 Jun 2012 at 0:31:48 +0200, Rodolfo kix Garcia wrote:
On 19/06/12 00:05, Carlos R. Mafra wrote:
On Mon, 18 Jun 2012 at 23:11:27 +0200, Rodolfo García Peñas wrote:
Subject: [PATCH 05/12] Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but 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 is always called.
---
src/appicon.c |3 +++
src/application.c | 23 ++-
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/appicon.c b/src/appicon.c
index c19efa0..ed4403c 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -975,6 +975,9 @@ void app_icon_create_from_docks(WWindow *wwin,
WApplication *wapp, Window main_w
{
WScreen *scr = wwin-screen_ptr;
+ /* Create the application icon */
+ wapp-app_icon = NULL;
+
if (scr-last_dock)
wapp-app_icon = findDockIconFor(scr-last_dock, main_window);
diff --git a/src/application.c b/src/application.c
index be305b2..f29e90f 100644
--- a/src/application.c
+++ b/src/application.c
@@ -158,20 +158,17 @@ WApplication *wApplicationCreate(WWindow * wwin)
/* application descriptor */
XSaveContext(dpy, main_window, wAppWinContext, (XPointer) wapp);
- /* Create the application icon */
- wapp-app_icon = NULL;
- if (!WFLAGP(wapp-main_window_desc, no_appicon)) {
- /* Create the application icon using the icon from docks
- * If not found in docks, create a new icon
- * using the function wAppIconCreate() */
- app_icon_create_from_docks(wwin, wapp, main_window);
-
- /* Now, paint the icon */
- paint_app_icon(wapp);
+ /* Create the application icon using the icon from docks
+ * If not found in docks, create a new icon
+ * using the function wAppIconCreate() */
+ app_icon_create_from_docks(wwin, wapp, main_window);
It's just a small detail, but I think it is more natural to create the
appicon calling a function named wAppIconCreate() instead of calling
app_icon_create_from_docks() which ultimately calls wAppIconCreate()
if the icon is not found in the dock.
Yes. Probably the name of app_icon_create_from_docks is incorrect, but
I think is better have the code in this function and outside of the
wApplicationCreate function. Now the application creation is more clear.
And, yes, the name is better wAppIconCreate. But the code in this
function is like the code in wAppIconCreateForDock. I tried join both
functions, but I leave it (time).
I will think about it.
Ok, no worries about that.
I just had this thought when I read the above comment and checked
the app_icon_create_from_docks(), it seemed odd to create an
icon like that.
BTW, I think the function name should be create_appicon_from_dock(),
it reads better.
Small patch done :-)
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Icon painting moved to makeAppIconFor()
On 17/06/12 19:28, Carlos R. Mafra wrote: On Fri, 15 Jun 2012 at 23:06:18 +0200, Rodolfo García Peñas wrote: Subject: [PATCH] Icon painting moved to makeAppIconFor() The icon painting is moved to the function makeAppIconFor() including the check for no_appicon. wAppIconCreate is now static because is only used in makeAppIconFor() The function is moved above to avoid the prototype creation. No, moving the position of a function inside the same file to avoid the prototype is not a good reason. It makes the patch artificially bigger and does not set a good precedent. Yes, but I thougth that the final code is better without the prototype. Could you please respin the patch without the moving? Yes, of course. I just sent it. Furthermore, does any of your later patches depend on your experimental ones? No. The experimental patch was only a try. I am happy with the comments about it, and for this reason I made this new patches. This patches includes the removal of the extractIcon function and the movement of the code of icon creation in application.c to appicon.c (this patch, with creation and painting moved to makeAppIconFor()). We don't need (at least now) split the creation and paint, because I did it in the makeAppIconFor using the check of the no_appicon, as you recomend. I think that these two patches do the same work that the experimental patches, but with better code. I will think a little more about the icon creation and painting, I think the work is not finished yet, but is better now. Again, thanks for your comments and your patch review. Best Regards, kix. --- src/appicon.c | 93 ++--- src/appicon.h |1 - src/application.c |4 --- 3 files changed, 46 insertions(+), 52 deletions(-) -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Icon painting moved to makeAppIconFor()
On 18/06/12 00:10, Rodolfo kix Garcia wrote: On 17/06/12 19:28, Carlos R. Mafra wrote: On Fri, 15 Jun 2012 at 23:06:18 +0200, Rodolfo García Peñas wrote: Subject: [PATCH] Icon painting moved to makeAppIconFor() The icon painting is moved to the function makeAppIconFor() including the check for no_appicon. wAppIconCreate is now static because is only used in makeAppIconFor() The function is moved above to avoid the prototype creation. No, moving the position of a function inside the same file to avoid the prototype is not a good reason. It makes the patch artificially bigger and does not set a good precedent. Yes, but I thougth that the final code is better without the prototype. Could you please respin the patch without the moving? Yes, of course. I just sent it. Furthermore, does any of your later patches depend on your experimental ones? No. The experimental patch was only a try. I am happy with the comments about it, and for this reason I made this new patches. This patches includes the removal of the extractIcon function and the movement of the code of icon creation in application.c to appicon.c (this patch, with creation and painting moved to makeAppIconFor()). We don't need (at least now) split the creation and paint, because I did it in the makeAppIconFor using the check of the no_appicon, as you recomend. I think that these two patches do the same work that the experimental patches, but with better code. Of course, if you have questions, please don't hesistate to contact me! The first patch is big. The idea is remove the extracIcon function and move the code to the save_app_icon function. The function calls wIconStore(). This function just do the same work that extractIcon, but we don't need call extractIcon+wIconStore (twice). kix I will think a little more about the icon creation and painting, I think the work is not finished yet, but is better now. Again, thanks for your comments and your patch review. Best Regards, kix. --- src/appicon.c | 93 ++--- src/appicon.h |1 - src/application.c |4 --- 3 files changed, 46 insertions(+), 52 deletions(-) -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] New save_app_icon and extractIcon removed
On 18/06/12 00:31, Carlos R. Mafra wrote: On Fri, 15 Jun 2012 at 20:21:57 +0200, Rodolfo García Peñas wrote: This commit includes: Application.c: - The appicon is always created and saved, only painted if needed. - The extractIcon function is removed, because their behaiour is done by save_app_icon. Now save_app_icon is called allways, if no_appicon is set or not. Because the extractIcon is removed, the function GetProgramNameForWindow (misc.c) can be deleted. - The app_icon stuff is moved from application.c to appicon.c: - wApplicationExtractDirPackIcon() moved and now static. - app_icon_create_from_docks() moved and now is not static, because this the only function is called in application.c - findDockIconFor() moved (was and is static). - wApplicationSaveIconPathFor() moved and now static. - Some includes and externs removed in application.c. Appicon.h: - wAppIconChangeImage() revoved, because is only declared. --- src/appicon.c | 189 +++-- src/appicon.h | 11 ++-- src/application.c | 171 +++- src/application.h |4 -- src/icon.c|2 +- src/misc.c|6 -- 6 files changed, 171 insertions(+), 212 deletions(-) This change is too big, and it looks like there's too much moving of functions. Just suppose that this commit introduces a regression. I think this patch needs to be split. It's doing too much at the same time. Ok, I will do it tomorrow, emmhhmm today but in a few hours. I need sleep. Please, check the patches and tell me what do you think. Tomorrow I will sent the patches with your comments+ideas included. good nigth. kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Experimental patch
El 12.06.2012 09:24, Carlos R. Mafra escribió: On Tue, 12 Jun 2012 at 7:49:47 +0200, Rodolfo kix Garcia wrote: To do it, I created two patches. The first patch breaks the dependency between create+paint an icon. Now, if we create an icon, we call wIconCreate. If we needs paint it, then calls paint_icon. Your patch does not seem to quite match your description, you removed the paint_icon() call from wIconUpdate() and added it right after all 11 calls to wIconUpdate(). So it looks like this is related to update and not create. Yes. This is because wIconUpdate is used in two cases: 1. When the icon is created (wIconCreate), we call wIconUpdate to finish the icon creation. Really is like wIconCreate is splitted in wIconCreate and wIconUpdate. 2. When the icon changes in X11. When the icon changes, then we call wIconUpdate. We don't need call wIconCreate, because the struct is created and only the icon could be modified. But... really we need paint the icon? For example, we need paint the icon when is updated and no_appicon is set? IMO No. This is the reason because I did this change, probably we need tweak it a little the different cases and check if we need call always paint_icon. Wouldn't it be better to simply check for no_appicon inside wIconPaint() and return early if it is set? That makes more sense to me. Yes! I will create a new patch with it this evening. This patch do the changes more visual (easiest), but your proposal is better++. Probably with your proposal (I need think about it) we don't need split the wIconCreate and wIconUpdate, but I am not sure. [snip] PS. Carlos, you get the Yast2 icon? I was already getting the correct icon before the patch too, since updating to openSUSE 12.1 :-) The problem is OpenSUSE then ;-) In Debian we don't have these problems :-P But there is a problem with your patch. I don't have time now, but the icons are not positioned at the botton left of the screen, they are shifted around 100 pixels to the right. Be careful with this problem. Sometime ago, I made some modifications and if we map the icon in X11 (even hidden), the space of the icon is busy for the icon, then X11 don't place icons in that place. Some of my previous patches prepared the code for this experimental patch, therefore this problem should not happen. An example of the problem: 1. We launch an application. The icon is shown. 2. Set the no_appicon flag. The icon is hidden. 3. If the icon is hidden, but mapped, the space of the icon is busy These patches, I think, do the hidden+unmap and the show+map joined. Please, be sure that we don't have this problem. Thanks a lot for your comments! kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Experimental patch
El 12.06.2012 00:57, Carlos R. Mafra escribió: On Mon, 11 Jun 2012 at 23:28:01 +0200, Rodolfo kix Garcia wrote: I did this experimental patch. I sent it compressed because I want to explain it (using my poor english). It's not a good idea to send compressed patches. Less people will see it. Yes, I know it. Sorry, but I don't want the developers spent a lot of time with the first patch. I want the developers understand the idea. The idea of this patch is break the current icon creation. Now, when a new aplication is launched, the function wApplicationCreate is called, then it search an icon (extractIcon function), then check if the application needs an icon (no_appicon set) and then create the application icon, save it (again??) and paint it. IMO this is an error. The application should create the icon allways, then save it (if was not previously created), and then check if the application needs appicon (no_appicon set) then paint or not it. I agree with you. To do it, I created two patches. The first patch breaks the dependency between create+paint an icon. Now, if we create an icon, we call wIconCreate. If we needs paint it, then calls paint_icon. Your patch does not seem to quite match your description, you removed the paint_icon() call from wIconUpdate() and added it right after all 11 calls to wIconUpdate(). So it looks like this is related to update and not create. Yes. This is because wIconUpdate is used in two cases: 1. When the icon is created (wIconCreate), we call wIconUpdate to finish the icon creation. Really is like wIconCreate is splitted in wIconCreate and wIconUpdate. 2. When the icon changes in X11. When the icon changes, then we call wIconUpdate. We don't need call wIconCreate, because the struct is created and only the icon could be modified. But... really we need paint the icon? For example, we need paint the icon when is updated and no_appicon is set? IMO No. This is the reason because I did this change, probably we need tweak it a little the different cases and check if we need call always paint_icon. But regardless of that, I think we should leave the paint_icon() call inside wIconUpdate(). There is no downside and we avoid the repetition (11 times!) of those lines right after wIconUpdate(). The second patch do the main work. The application is created, calls to wApplicationCreate, create the icon, save it, check if no_appicon is needed, then calls paint_appicon. Now, the icon in the switchpanel shows the icon, always, and the icon in the appicon is the the same icon. The second patch is really nice! Especially the removal of extractIcon() and the extra wAppIconSave(). But I did not understand why you still want to create the appicon even if no_appicon is set. Isn't that a waste of energy? What am I missing? Yes. Reasons: 1. We remove extracIcon, but we need save the icon in CachedPixmaps because the icon can be used when we dock the application. Then we must create the icon, and then save it. 2. The appicon is used in three different parts of the code. As appicon (the app icon), as miniwindow (the icon when the application is minimized) and the icon in the switchpanel (alt + tab). The icon in the docks is icon saved in CachedPixmaps previously, but is the same icon than the other three cases. Now, with this code, the icon is created always. Is a waste of energy, no; because for example, if we create an application without appicon, we will still use the icon when we minimize the window, or if we make alt+tab. Why create the icon in that cases and then remove it. For example if I do alt+tab three times, the icon is created, updated, painted and removed three times! This is the idea of these patches: 1. Create the icon ONE time in the code. 2. Update it when needed: When is created and if the icon changes in X11 3. Use the SAME icon in all parts of the code 4. Delete the icon only ONE time in the code. We can remove more code with this idea, because wApplication-AppIcon always exists, for example the function addIconForWindow() in the switchpanel.c always will find the icon in wapp-appicon-icon, then it don't needs finds (and creates if not found) the image. Best Regards, kix PS. Carlos, you get the Yast2 icon? -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
The other patches
Hi Carlos, is possible apply the other patches (5 to 9)? If you find them interesting, please, apply them. The last patch (10) is not needed now. Thanks. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 03/10] New functions in icon.c
El 09.06.2012 18:28, Carlos R. Mafra escribió:
On Thu, 7 Jun 2012 at 23:45:02 +0200, Rodolfo García Peñas wrote:
One more thing I noticed.
+static char *get_icon_cache_path(void)
+{
+ char *prefix, *path;
+ int len, ret;
+
+ prefix = wusergnusteppath();
+ len = strlen(prefix) + strlen(CACHE_ICON_PATH) + 1;
+ path = wmalloc(len);
+ snprintf(path, len, %s%s, prefix, CACHE_ICON_PATH);
+
+ ret = create_path(path);
You define create_path() only in the next patch, you must do it
before
using it.
Yes, of course. The problem is that I wrote some patches, then I split
that patches to send to the mail list, to better understanding. I try to
avoid these problems, but... sorry.
And I must say I don't like your create_path() being able to create
stuff outside the GNUstep folder. Can't you use the wmkdirhier() from
the WINGs library instead?
I am working on it. Thanks a lot for your suggestion. Is so incredible
how you can know what functions exists :-)
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 03/10] New functions in icon.c
El 09.06.2012 18:38, Carlos R. Mafra escribió:
On Sat, 9 Jun 2012 at 17:05:58 +0100, Carlos R. Mafra wrote:
On Thu, 7 Jun 2012 at 23:45:02 +0200, Rodolfo García Peñas wrote:
Subject: [PATCH 03/10] New functions in icon.c
This patch creates some functions:
+
+static RImage *get_wwindow_image_from_wmhints(WWindow *wwin,
WIcon *icon)
+{
+ RImage *image;
+
+ if (wwin-wm_hints
+ (wwin-wm_hints-flags IconPixmapHint)
+ wwin-wm_hints-icon_pixmap != None) {
+ image =
RCreateImageFromDrawable(icon-core-screen_ptr-rcontext,
+ wwin-wm_hints-icon_pixmap,
+ (wwin-wm_hints-flags
IconMaskHint)
+ ? wwin-wm_hints-icon_mask :
None);
+ }
+ return image;
+}
This function does not seem right - 'image' will be a random pointer
if
the conditions are false. You should initialize it to NULL.
Sorry, you did exactly this on patch 10. But you should have done it
here already.
Not sorry. I did it wrong.
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] New functions in icon.c
El 10.06.2012 00:47, Carlos R. Mafra escribió: On Sat, 9 Jun 2012 at 23:56:18 +0200, Rodolfo García Peñas wrote: Subject: [PATCH] New functions in icon.c This patch creates some functions: 1. Rename getnameforicon() to get_name_for_icon() 2. New function get_icon_cache_path, to get the icon cache folder ($HOME + GNUstep/Library/WindowMaker/CachedPixmaps). This folder is defined now in the preprocessor. Not used yet, in next commits. 3. New function get_wwindow_image_from_wmhints to read the image from X11 wmhints. Previous code at wIconStore() now changed. Thanks. Thank you, I am working in the 0004 patch. I will send it soon. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Bug creating icon
Hi, I found a bug when creating an icon. Is only with xterm (not xeyes, other apps). To reproduce it: 1. Remove the terminal icon configuration from your files. Remove the icon cache (see below). Now, when we launch xterm, we need to recreate the icon. Then crash. If you try to do it again, you don't have problems. Then, delete the xterm.XTerm.xpm file form GNUstep/Library/WindowMaker/CacheIcons/ folder. The problem is at RSaveXPM function, at nxpm.c file (wrlib). The image struct don't have info? It crash when trying to compare, in if (image-format == RRGBAFormat) a = image-data + 3; else a = NULL; If you comment these lines, then will crash in image-data Can somebody check if the problem is common? Help to solve it? Thanks. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Bug creating icon
El 07.06.2012 13:29, Rodolfo kix Garcia escribió: Hi, I found a bug when creating an icon. Is only with xterm (not xeyes, other apps). To reproduce it: 1. Remove the terminal icon configuration from your files. Remove the icon cache (see below). Now, when we launch xterm, we need to recreate the icon. Then crash. If you try to do it again, you don't have problems. Then, delete the xterm.XTerm.xpm file form GNUstep/Library/WindowMaker/CacheIcons/ folder. The problem is at RSaveXPM function, at nxpm.c file (wrlib). The image struct don't have info? It crash when trying to compare, in if (image-format == RRGBAFormat) a = image-data + 3; else a = NULL; If you comment these lines, then will crash in image-data Can somebody check if the problem is common? Help to solve it? Problem found. image should be initialized to NULL. I am doing a patch. Regards. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
WMInitializeApplication
Hi, there is a function to remove the information created by WMInitializeApplication? Something like WMDestroyApplication. ==4316== 16 bytes in 1 blocks are still reachable in loss record 9 of 20 ==4316==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==4316==by 0x40AE22E: wmalloc (memory.c:80) ==4316==by 0x40B4E7C: WMInitializeApplication (wapplication.c:42) ==4316==by 0x42D306: main (main.c:608) The struct should be wfreeded before finish windowmaker. Thanks. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
valgrind
==by 0x40AE22E: wmalloc (memory.c:80) ==5027==by 0x40ADB2A: WMCreateHashTable (hashtable.c:100) ==5027==by 0x40AE7B1: W_InitNotificationCenter (notification.c:93) ==5027==by 0x42D306: main (main.c:608) ==5027== ==5027== 64 bytes in 1 blocks are still reachable in loss record 16 of 20 ==5027==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==5027==by 0x40AE22E: wmalloc (memory.c:80) ==5027==by 0x40AA24E: WMCreateArrayWithDestructor (array.c:41) ==5027==by 0x42D322: main (main.c:612) ==5027== ==5027== 66 bytes in 1 blocks are still reachable in loss record 17 of 20 ==5027==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==5027==by 0x40AE22E: wmalloc (memory.c:80) ==5027==by 0x42D814: main (main.c:643) ==5027== ==5027== 184 bytes in 1 blocks are still reachable in loss record 18 of 20 ==5027==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==5027==by 0x40AE22E: wmalloc (memory.c:80) ==5027==by 0x40ADB61: WMCreateHashTable (hashtable.c:106) ==5027==by 0x40AE74E: W_InitNotificationCenter (notification.c:90) ==5027==by 0x42D306: main (main.c:608) ==5027== ==5027== 184 bytes in 1 blocks are still reachable in loss record 19 of 20 ==5027==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==5027==by 0x40AE22E: wmalloc (memory.c:80) ==5027==by 0x40ADB61: WMCreateHashTable (hashtable.c:106) ==5027==by 0x40AE786: W_InitNotificationCenter (notification.c:91) ==5027==by 0x42D306: main (main.c:608) ==5027== ==5027== 184 bytes in 1 blocks are still reachable in loss record 20 of 20 ==5027==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==5027==by 0x40AE22E: wmalloc (memory.c:80) ==5027==by 0x40ADB61: WMCreateHashTable (hashtable.c:106) ==5027==by 0x40AE7B1: W_InitNotificationCenter (notification.c:93) ==5027==by 0x42D306: main (main.c:608) ==5027== ==5027== LEAK SUMMARY: ==5027==definitely lost: 24 bytes in 1 blocks ==5027==indirectly lost: 0 bytes in 0 blocks ==5027== possibly lost: 0 bytes in 0 blocks ==5027==still reachable: 955 bytes in 19 blocks ==5027== suppressed: 0 bytes in 0 blocks ==5027== ==5027== For counts of detected and suppressed errors, rerun with: -v ==5027== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6) -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: valgrind
El 01.06.2012 14:34, Rodolfo kix Garcia escribió: For your information, a valgrind output, only start and finish windowmaker with some windows + dockapp: I will re-run valgrind with wmaker --for-real, after send my patches. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: WMInitializeApplication
El 01.06.2012 15:38, Carlos R. Mafra escribió: On Fri, 1 Jun 2012 at 14:27:13 +0200, Rodolfo kix Garcia wrote: Hi, there is a function to remove the information created by WMInitializeApplication? Something like WMDestroyApplication. ==4316== 16 bytes in 1 blocks are still reachable in loss record 9 of 20 ==4316==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==4316==by 0x40AE22E: wmalloc (memory.c:80) ==4316==by 0x40B4E7C: WMInitializeApplication (wapplication.c:42) ==4316==by 0x42D306: main (main.c:608) The struct should be wfreeded before finish windowmaker. Note that if something is not free()'ed only when terminating wmaker, this is not a problem. The kernel will free that memory. Yes :-) but is because is still reachable? there are other leaks not reachable. IMO the correct way is free the memory used. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Help. Quick test with the current next binary
El 31.05.2012 17:54, Carlos R. Mafra escribió: On Thu, 31 May 2012 at 17:20:30 +0200, Rodolfo kix Garcia wrote: Hi, please, can anyone using the current next brach (updated) to check if there is a bug? 1. Launch any application 2. Open the properties 3. Click on Reload I didn't have this problem with the debian binary, but yes with my developer binary at /usr/local/bin. I don't see any obvious problem with clicking the Reload button here. What kind of problem do you see? Hi Carlos, thanks for your reply. wmaker restarts, this is the problem: Program received signal SIGSEGV, Segmentation fault. WMDrawString (scr=0x18d6b70, d=6293195, color=0x141, font=0x18dcb50, x=145, y=78, text=0x1a11ef0 Min iwindow Image, length=16) at wfont.c:270 270 xftcolor.color.red = color-color.red; (gdb) bt #0 WMDrawString (scr=0x18d6b70, d=6293195, color=0x141, font=0x18dcb50, x=145, y=78, text=0x1a11ef0 Miniwindow Image, length=16) at wfont.c:270 #1 0x7f74ec47b5fa in W_PaintText (view=0x1a11d40, d=6293195, font=0x18dcb50, x=4, y=78, width=25 2, alignment=WARight, color=0x141, wrap=1, text=0x1a11ef0 Miniwindow Image, length=16) at wmisc.c:187 #2 0x7f74ec47b949 in W_PaintTextAndImage (view=0x1a11d40, wrap=1, textColor=0x141, font=0x18dcb5 0, relief=WRFlat, text=0x1a11ef0 Miniwindow Image, alignment=WARight, image=0x0, position=14, backColor=0x0, ofs= 0) at wmisc.c:304 #3 0x7f74ec468787 in paintButton (bPtr=optimized out) at wbutton.c:589 #4 0x7f74ec4695dd in WMSetButtonSelected (bPtr=0x1a11d10, isSelected=optimized out) at wbutton .c:373 #5 0x00456fad in revertSettings (button=optimized out, panel=0x19bcaf0) at winspector.c:97 0 #6 0x7f74ec472456 in WMHandleEvent (event=0x7fff9f865190) at wevent.c:271 #7 0x00427b77 in EventLoop () at event.c:408 #8 0x0042d651 in real_main (argv=optimized out, argc=2) at main.c:850 #9 main (argc=2, argv=optimized out) at main.c:650 (gdb) -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Help. Quick test with the current next binary
El 31.05.2012 18:33, Carlos R. Mafra escribió: On Thu, 31 May 2012 at 18:03:10 +0200, Rodolfo kix Garcia wrote: El 31.05.2012 17:54, Carlos R. Mafra escribió: On Thu, 31 May 2012 at 17:20:30 +0200, Rodolfo kix Garcia wrote: Hi, please, can anyone using the current next brach (updated) to check if there is a bug? 1. Launch any application 2. Open the properties 3. Click on Reload I didn't have this problem with the debian binary, but yes with my developer binary at /usr/local/bin. I don't see any obvious problem with clicking the Reload button here. What kind of problem do you see? Hi Carlos, thanks for your reply. wmaker restarts, this is the problem: Program received signal SIGSEGV, Segmentation fault. Ok, I definitely can't trigger it. Can you (git) bisect this? Hi Carlos, I think the problem is at commit c82138eab959bc4f73b5c49de209188aab25b2a0 (Haroldo Santos's patch, in cc:). (http://repo.or.cz/w/wmaker-crm.git/commitdiff/c82138eab959bc4f73b5c49de209188aab25b2a0) The previous commit (wmgenmenu: Add French and Spanish translations) don't have the problem. I have not time now to make a patch. I will try to check it soon (but not today), because I spent a lot of time trying to see if my new patches has bugs. If you (or Haroldo) can check it, perfect. I am busy these days :-( Regards. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : Re : Re: Help. Quick test with the current next binary
El 31.05.2012 20:50, Christophe escribió:
Hi Carlos,
While we're at it, could I propose the attached patch instead? It
does the same thing and a few more I did not search for the first
time.
Regards,
Christophe.
Hi,
1st, I applied the patch (really, I copied and pasted) over
c82138eab959bc4f73b5c49de209188aab25b2a0 commit. The problem seems to be
gone. Thanks a lot!
2nd, I have some comments about the patch:
I think that
for (i = 0; i (sizeof(panel-appChk)/sizeof(panel-appChk[0])); i++)
should be (see space+/+space)
for (i = 0; i (sizeof(panel-appChk) / sizeof(panel-appChk[0]));
i++)
And one line has tabs+spaces. Please, change the spaces by one tab:
@@ -970,7 +970,7 @@ static void revertSettings(WMButton * button,
InspectorPanel * panel)
WMSetButtonSelected(panel-moreChk[i], flag);
}
if (panel-appFrm wapp) {
- for (i = 0; i 3; i++) {
+ for (i = 0; i (sizeof(panel-appChk)/sizeof(panel-appChk[0]));
i++) {
int flag = 0;
The patch is very good, the part with ifdef is ugly in the original
source :-)
Carlos, Christophe, thanks for your quick help. I will continue with my
patches.
Cheers.
kix
- Christophe christophe.cu...@free.fr a écrit :
Hi Rodolfo,
Could you please have a try at the patch attached below? it may (or
may not) solve the problem.
Carlos,
Considering the nature of the patch, I'd suggest to include it
anyway if its fits your standards.
Regards,
Christophe.
- Rodolfo kix Garcia k...@kix.es a écrit :
El 31.05.2012 18:33, Carlos R. Mafra escribió:
On Thu, 31 May 2012 at 18:03:10 +0200, Rodolfo kix Garcia wrote:
El 31.05.2012 17:54, Carlos R. Mafra escribió:
On Thu, 31 May 2012 at 17:20:30 +0200, Rodolfo kix Garcia
wrote:
Hi,
please, can anyone using the current next brach (updated) to
check
if there is a bug?
1. Launch any application
2. Open the properties
3. Click on Reload
I didn't have this problem with the debian binary, but yes
with my
developer binary at /usr/local/bin.
I don't see any obvious problem with clicking the Reload
button
here.
What kind of problem do you see?
Hi Carlos,
thanks for your reply. wmaker restarts, this is the problem:
Program received signal SIGSEGV, Segmentation fault.
Ok, I definitely can't trigger it. Can you (git) bisect this?
Hi Carlos,
I think the problem is at commit
c82138eab959bc4f73b5c49de209188aab25b2a0 (Haroldo Santos's patch,
in
cc:).
(http://repo.or.cz/w/wmaker-crm.git/commitdiff/c82138eab959bc4f73b5c49de209188aab25b2a0)
The previous commit (wmgenmenu: Add French and Spanish
translations)
don't have the problem.
I have not time now to make a patch. I will try to check it soon
(but
not today), because I spent a lot of time trying to see if my new
patches has bugs. If you (or Haroldo) can check it, perfect. I am
busy
these days :-(
Regards.
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to
wmaker-dev-unsubscr...@lists.windowmaker.org.
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : Re : Re: Help. Quick test with the current next binary
El 01.06.2012 00:05, Carlos R. Mafra escribió: On Thu, 31 May 2012 at 23:56:10 +0200, Rodolfo kix Garcia wrote: El 31.05.2012 20:50, Christophe escribió: Hi Carlos, While we're at it, could I propose the attached patch instead? It does the same thing and a few more I did not search for the first time. Regards, Christophe. Hi, 1st, I applied the patch (really, I copied and pasted) over c82138eab959bc4f73b5c49de209188aab25b2a0 commit. The problem seems to be gone. Thanks a lot! Thanks for the confirmation. I will apply the patch after modifying the minor coding style issue. Thanks a lot Christophe! Confirmed, I apply the patch to the next branch with my patches and the problem is gone. Thanks Christophe. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Symbol problem
El 24.05.2012 12:32, Rodolfo kix Garcia escribió: Hi, I get this error [1]. I cannot find where the problem is. W_DraggingInfo is defined at WINGs.h Any help? I found the problem, now W_DraggingInfo is declared as typedef W_DraggingInfo in the file WINGsP.h I will remove the symbol in the next debian package. Cheers. Thanks. [1] dpkg-gensymbols: aviso: han desaparecido algunos símbolos o patrones en el fichero «symbols»: «vea la salida del «diff» a continuación» dpkg-gensymbols: aviso: «debian/libwutil2/DEBIAN/symbols» no encaja totalmente con «debian/libwutil2.symbols» --- debian/libwutil2.symbols (libwutil2_0.95.3-1_amd64) +++ dpkg-gensymbols9rAgaA 2012-05-24 12:27:12.0 +0200 @@ -190,7 +190,7 @@ W_ApplicationInitialized@Base 0.95.0 W_CheckIdleHandlers@Base 0.95.0 W_CheckTimerHandlers@Base 0.95.0 - W_DraggingInfo@Base 0.95.0 +#MISSING: 0.95.3-1# W_DraggingInfo@Base 0.95.0 W_FlushASAPNotificationQueue@Base 0.95.0 W_FlushIdleNotificationQueue@Base 0.95.0 W_HandleInputEvents@Base 0.95.0 dh_makeshlibs: dpkg-gensymbols -plibwutil2 -Idebian/libwutil2.symbols -Pdebian/libwutil2 returned exit code 1 make: *** [binary] Error 1 -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: tgz file for version 0.53
El 23.05.2012 18:57, Renato Botelho escribió: On Wed, May 23, 2012 at 1:11 PM, John H. Robinson, IV jaq...@sbih.org wrote: Rodolfo kix Garcia wrote: El 23.05.2012 17:03, Carlos R. Mafra escribi??: On Wed, 23 May 2012 at 16:53:29 +0200, Rodolfo kix Garcia wrote: where is the wmaker_0.53 tar.gz file in the webpage? I will create the debian package using this file. Assuming you meant version 0.95.3, it's not in the webpage. You can download it from http://repo.or.cz/w/wmaker-crm.git/snapshot/efcad8497ee6c89683919e505973e08639ecad87.tar.gz Thanks Carlos, I will use this file as wmaker-0.95.3.orig.tgz in debian distro. NO Unsuitable I didn't realise 0.95.3 was tagged and good... I'll get that tarball up Thanks, this is the best way for packagers. -- Renato Botelho Hi, I have a question because I don't understand one thing. Why we cannot use the file http://repo.or.cz/w/wmaker-crm.git/snapshot/efcad8497ee6c89683919e505973e08639ecad87.tar.gz; as tarball (ok, renamed to wmaker-0.95.3.tar.gz and in the folder windowmaker.org/pub/source/release/)? Why we need run ./autogen.sh ./configure make dist?? Make dist creates some Makefile and Makefile.in files,... Why is not better use the original source file without running these commands? Also, the autotools could be different between the file and the distro. Thanks for your help, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: tgz file for version 0.53
El 24.05.2012 10:21, Andreas Tscharner escribió: On 24.05.2012 10:05, Rodolfo kix Garcia wrote: [snip] Why we cannot use the file http://repo.or.cz/w/wmaker-crm.git/snapshot/efcad8497ee6c89683919e505973e08639ecad87.tar.gz; as tarball (ok, renamed to wmaker-0.95.3.tar.gz and in the folder windowmaker.org/pub/source/release/)? Why we need run ./autogen.sh ./configure make dist?? Make dist creates some Makefile and Makefile.in files,... Why is not better use the original source file without running these commands? Also, the autotools could be different between the file and the distro. Yes, but there may be people that don't have the autotools installed. And ./autogen.sh creates the Makefile.in and the ./configure script. So people can compile and install it (from source) even without the autotools... Thanks Andreas, then, I will wait John upload the file to windowmaker.org/pub/source/release/ kix Best regards Andreas -- (`-''-/).___..--''`-._ `o_ o ) `-. ( ).`-.__.`) (_Y_.)' ._ ) `._ `. ``-..-' _..`--'_..-_/ /--'_.' .' (il).-'' (li).' ((!.-' Andreas Tscharner a...@vis.ethz.ch ICQ-No. 14356454 -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Symbol problem
Hi, I get this error [1]. I cannot find where the problem is. W_DraggingInfo is defined at WINGs.h Any help? Thanks. [1] dpkg-gensymbols: aviso: han desaparecido algunos símbolos o patrones en el fichero «symbols»: «vea la salida del «diff» a continuación» dpkg-gensymbols: aviso: «debian/libwutil2/DEBIAN/symbols» no encaja totalmente con «debian/libwutil2.symbols» --- debian/libwutil2.symbols (libwutil2_0.95.3-1_amd64) +++ dpkg-gensymbols9rAgaA 2012-05-24 12:27:12.0 +0200 @@ -190,7 +190,7 @@ W_ApplicationInitialized@Base 0.95.0 W_CheckIdleHandlers@Base 0.95.0 W_CheckTimerHandlers@Base 0.95.0 - W_DraggingInfo@Base 0.95.0 +#MISSING: 0.95.3-1# W_DraggingInfo@Base 0.95.0 W_FlushASAPNotificationQueue@Base 0.95.0 W_FlushIdleNotificationQueue@Base 0.95.0 W_HandleInputEvents@Base 0.95.0 dh_makeshlibs: dpkg-gensymbols -plibwutil2 -Idebian/libwutil2.symbols -Pdebian/libwutil2 returned exit code 1 make: *** [binary] Error 1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
tgz file for version 0.53
Hi! where is the wmaker_0.53 tar.gz file in the webpage? I will create the debian package using this file. Thanks! -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: tgz file for version 0.53
El 23.05.2012 17:03, Carlos R. Mafra escribió: On Wed, 23 May 2012 at 16:53:29 +0200, Rodolfo kix Garcia wrote: where is the wmaker_0.53 tar.gz file in the webpage? I will create the debian package using this file. Assuming you meant version 0.95.3, it's not in the webpage. You can download it from http://repo.or.cz/w/wmaker-crm.git/snapshot/efcad8497ee6c89683919e505973e08639ecad87.tar.gz Thanks Carlos, I will use this file as wmaker-0.95.3.orig.tgz in debian distro. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: tgz file for version 0.53
El 23.05.2012 17:21, Carlos R. Mafra escribió: On Wed, 23 May 2012 at 17:16:53 +0200, Rodolfo kix Garcia wrote: El 23.05.2012 17:03, Carlos R. Mafra escribió: On Wed, 23 May 2012 at 16:53:29 +0200, Rodolfo kix Garcia wrote: where is the wmaker_0.53 tar.gz file in the webpage? I will create the debian package using this file. Assuming you meant version 0.95.3, it's not in the webpage. You can download it from http://repo.or.cz/w/wmaker-crm.git/snapshot/efcad8497ee6c89683919e505973e08639ecad87.tar.gz Thanks Carlos, I will use this file as wmaker-0.95.3.orig.tgz in debian distro. You can use 'make dist' in your copy of the git repo. That will create a standard tarball for a distro. I was looking for the tar.gz file in the web, to use the same file in all distros. IMO we should create a link in the webpage to a tgz file for the stable version. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Paths (again)
I am working in the debian package, and I have a problem with paths, again. The problem is with the configuration files (/etc in debian). See the previous thread here: http://www.mail-archive.com/wmaker-dev@lists.windowmaker.org/msg01432.html In this debian package version (0.95.3), I will continue using /etc/GNUstep/Defaults, to avoid delay in the package creation. But, I think that I should change the folder in future versions in upstream. The main problem is the uniformity between the files in /etc and the files in $HOME, because they should be the same structure. OTOH WindowMaker don't have relation with GNUstep now, therefore, we should change the GNUstep to other thing, probably WindowMaker or wmaker. IMO, I prefer configuration files starting with dot in my home directory, therefore .WindowMaker or .wmaker could be a good idea, using then /etc/WindowMaker or /etc/wmaker. I think that we can make the change, because WindowMaker can search the configuration files using different folders (see defaults.c), and then, we can read the files at /home/user/.wmaker, if not exists, then at /home/user/GNUstep, else, the common files at /etc/wmaker, else /usr/.../WindowMaker/. Saludos, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] No need to call memset after wmalloc
El 04/05/2012 23:45, Carlos R. Mafra escribió:
On Fri, 4 May 2012 at 22:57:39 +0200, Tobias Stoeckmann wrote:
From 252e6e59b17d4477fec19b41f443b4c4c4bea908 Mon Sep 17 00:00:00 2001
From: Tobias Stoeckmann tob...@openbsd.org
Date: Fri, 4 May 2012 22:53:04 +0200
Subject: [PATCH] No need to call memset after wmalloc
Thanks for the patch. I have just one comment and it's not really
related to your patch.
diff --git a/WPrefs.app/Menu.c b/WPrefs.app/Menu.c
index 342e7f0..e9eaa9b 100644
--- a/WPrefs.app/Menu.c
+++ b/WPrefs.app/Menu.c
@@ -155,7 +155,7 @@ static char *commandNames[] = {
LEGAL_PANEL
};
-#define NEW(type) memset(wmalloc(sizeof(type)), 0, sizeof(type))
+#define NEW(type) wmalloc(sizeof(type))
I think it would be even better to get rid of the #define and use
wmalloc() directly in those few places.
+1
The patch is s good. Congrats.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Patch: Make maximize hotkeys more intuitive
Eh! nice patch :-)
I cannot check more deeply now, but, some comments:
El 04/05/2012 18:48, Iain Patterson escribió:
+void handleMaximize(WWindow *wwin, int directions)
+{
+ int current = wwin-flags.maximized;
+ int requested = directions (MAX_HORIZONTAL | MAX_VERTICAL |
MAX_LEFTHALF | MAX_RIGHTHALF | MAX_MAXIMUS);
+ int effective = requested ^ current;
+ int flags = directions ~requested;
+
+ if (!effective) {
+ /* allow wMaximizeWindow to restore the Maximusized size */
+ if ((wwin-flags.old_maximized MAX_MAXIMUS)
+ !(requested MAX_MAXIMUS))
+ wMaximizeWindow(wwin, flags);
+ else
+ wUnmaximizeWindow(wwin);
+ }
+ else {
+ /* MAX_MAXIMUS takes precedence */
Probably is better:
+ } else {
+ /* MAX_MAXIMUS takes precedence */
+ effective = ~MAX_MAXIMUS;
+ if (requested MAX_MAXIMUS) {
+ /* window was previously Maximusized then maximized */
+ if ((wwin-flags.old_maximized MAX_MAXIMUS)
!current) {
+ wUnmaximizeWindow(wwin);
+ return;
+ }
+ else
+ effective = MAX_MAXIMUS;
+ }
+ else if (requested == (MAX_HORIZONTAL | MAX_VERTICAL))
+ effective = requested;
+ else {
And here:
+ } else {
+ effective = MAX_MAXIMUS;
+ }
+ } else if (requested == (MAX_HORIZONTAL | MAX_VERTICAL)) {
+ effective = requested;
+ } else {
+ /* handle MAX_HORIZONTAL - MAX_(LEFT|RIGHT)HALF */
+ if (IS_MAX_HORIZONTALLY(current)) {
+ if (IS_MAX_HORIZONTALLY(requested)) {
+ effective = ~(MAX_HORIZONTAL |
MAX_LEFTHALF | MAX_RIGHTHALF);
+ effective |= (requested
(MAX_HORIZONTAL | MAX_LEFTHALF | MAX_RIGHTHALF));
+ if (requested MAX_HORIZONTAL) {
+ /* restore to half maximization
*/
+ if (wwin-flags.old_maximized
MAX_LEFTHALF)
+ effective |=
MAX_LEFTHALF;
+ else if
(wwin-flags.old_maximized MAX_RIGHTHALF)
+ effective |=
MAX_RIGHTHALF;
+ }
+ /* MAX_VERTICAL is implicit with
MAX_(LEFT|RIGHT)HALF */
+ else
+ effective |= MAX_VERTICAL;
The same idea } else { (above this line) ^
+ } else {
+ /* toggling MAX_VERTICAL */
+ if ((requested MAX_VERTICAL)
+ (current MAX_VERTICAL)) {
+ effective = ~(MAX_LEFTHALF |
MAX_RIGHTHALF | MAX_VERTICAL);
+ }
Curly brackets not needed (above)
+ }
+ }
+ /* handle MAX_VERTICAL - MAX_(LEFT|RIGHT)HALF */
+ if (current MAX_VERTICAL) {
+ if ((requested MAX_LEFTHALF) ||
+ (requested MAX_RIGHTHALF)) {
+ effective |= MAX_VERTICAL;
+ }
No curly brackets above ^
+ }
+ /* toggling MAX_HORIZONTAL */
+ if ((requested MAX_HORIZONTAL)
+ (current MAX_HORIZONTAL))
+ effective = ~MAX_HORIZONTAL;
+ }
+ wMaximizeWindow(wwin, effective | flags);
+ }
+ return;
}
/* the window boundary coordinates */
@@ -434,7 +569,14 @@ static void find_Maximus_geometry(WWindow *wwin, WArea
usableArea, int *new_x, i
win_coords obs, orig, new;
/* set the original coordinate positions of the window to be
Maximumized */
- set_window_coords(wwin, orig);
+ if (wwin-flags.maximized) {
+ /* window is already maximized; consider original geometry */
+ remember_geometry(wwin, orig.left, orig.top, orig.width,
orig.height);
+ orig.bottom = orig.top + orig.height;
+ orig.right = orig.left + orig.width;
+ }
+ else
+ set_window_coords(wwin, orig);
} else {
set_window_coords(wwin, orig);
}
Re: [PATCH 05/16] WindowMaker: wdefaults uses now StrConcatDot
El 20.04.2012 01:57, Carlos R. Mafra escribió: On Sun, 15 Apr 2012 at 23:09:39 +0200, Rodolfo García Peñas wrote: The new StrConcatDot function can be used now in wdefaults.c snip I will remove all patches regarding StrConcatDot() from #next, sorry. :-) no problem. I am busy now (debian packages). Can somebody do the changes between malloc + snprintf %s.%s to StrConcatDot? Is interesting to review some parts of code where I changed to StrConcatDot, the malloc functions are requesting more bytes than needed. Thanks. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 12/16] WindowMaker: Check iconPath variable only if needed
El 16.04.2012 18:38, Brad Jorsch escribió: On Mon, Apr 16, 2012 at 05:29:51PM +0200, Rodolfo kix Garcia wrote: Ok, the commit info is not accurate. If is initialized to NULL, then this part of the code is never used if we don't enter first in the if (strstr(path, .app)) block. OTOH, it may be considered clearer that the cleanup for the iconPath variable is run unconditionally rather than only inside the other if block. Sometimes (for a big number of sometimes), my English language is not fine. But the patch is ok :-) -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 16/16] WindowMaker: wIconStore() don't save the icon if exists
El 16.04.2012 18:42, Brad Jorsch escribió: On Mon, Apr 16, 2012 at 01:15:17PM -0300, Carlos R. Mafra wrote: Removing wIconStore seems sensible. I don't like the idea of icons being stored on disk, and there's no performance reason for doing that nowadays. Then where does wmaker find the icons for docked apps when they are not running? Good point. Then we should save the icon one time (on application starting). Save the icon in the Domain Database (loaded from the file WMAttributes) and use it. Thanks for your comment. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Bug: Erroneous PATH for some application icons.
Hi, about this problem, a little explanation, for example for firefox. 1. On my debian, I launch mozilla firefox using a terminal and typing iceweasel (name of firefox on debian) 2. iceweasel is a script. This script do exec /usr/lib/iceweasel/firefox-bin (see man exec). 3. X11 see that the program running is /usr/lib/iceweasel/firefox-bin a. WindowMaker, uses getCommandForWindow(Window win, int elements) (misc.c:1104) to ask X11 b. This function execs XGetCommand to read the Window command c. In this case, XGetCommand returns firefox-bin Problems: 1. I typed iceweasel but WindowMaker gets firefox-bin 2. firefox-bin is not in the path, the application cannot be launched. 3. If the application is in the path, really we want run the binary (without the script)? Cheers, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: AppIcons on clip
El 27.02.2012 23:08, Renan Traba escribió: I have a lot of icons on clip, when I move the clip, it moves slow, I can see that wmaker is moving one per one appicon When I move the dock, it move fast dont have a better way to move the appicon atatched to clip ? Sorry for the delay. Do you have more info? I can move the applications on clip and on dock without problems. You have the problem with the applications closed, open, both,... please, test it to get more info. Thanks a lot. kix -- Renan Vedovato Traba Aluno de Bacharelado em Ciência da Computação pela Universidade Federal do Paraná Linux Register n°: 525911 -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Fwd: Work-needing packages report for Mar 16, 2012
Hi, today, in the wnpr, three dock applications has been orphaned. Please, can someone maintain them? I am adopting other 2 from the last week. I can help with the package update. Regards, kix Mensaje original Asunto: Work-needing packages report for Mar 16, 2012 Fecha: 16.03.2012 02:27 Remitente: w...@debian.org Destinatario: debian-de...@lists.debian.org The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 440 (new: 11) Total number of packages offered up for adoption: 146 (new: 1) Total number of packages requested help for: 61 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. [snip] wmmail (#664096), orphaned today Description: A mail notification program designed for WindowMaker Installations reported by Popcon: 119 wmppp.app (#664097), orphaned today Description: PPP dial control and network load monitor with NeXTStep look Installations reported by Popcon: 68 wmrack (#664098), orphaned today Description: Combined CD Player + Mixer designed for WindowMaker Installations reported by Popcon: 70 [snip] See http://www.debian.org/devel/wnpp/help_requested for more information. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: WindowMaker: lost maximized status
On 26/02/12 14:43, Sergey Popov wrote: Hi, The old bug in WindowMaker (0.95.2). 0. Before reporting this bug I already: [ x] read the NEWS, README and INSTALL files [ x] read the list of already known bugs in the BUGS file [ x] downloaded and tried the latest version of WindowMaker 1. What happened: [ ] could not compile [ ] crashed [ ] configuration option does not work [x ] weird behaviour [ ] cosmetic [ ] some problem with WPrefs [ ] others: .. . 2. Detailed description of what happened: Maximized status of window is lost. 3. How to reproduce the bug, if known: - Start gvim gvim --servername qwe .gvimrc - Maximize (vertical, horizontal or full) created Gvim window - Open another (or same) file to the same Gvim window g --servername qwe --remote-silent .gvimrc - Try to restore Gvim window -- maximized status is lost. 4. Configure time options you specified: [ ] --enable-kanji [ ] --disable-shape [ ] --enable-single-icon [ ] --enable-modelock [x ] Others: run configure without parametes (all defaults) 5. Changes to the src/wconfig.h file: 6. The error occured during: [ ] configuration [ ] compilation [ ] startup [x ] use 7. Changes made to the configuration files, if the error ocurred during use: 8. Error messages output: 9. Fix, if known: I don't have enough time to locate it in code 10. Other Notes: This is old bug. I saw him at 0.91 or 0.92 My e-mail: psvor...@gmail.com mailto:psvor...@gmail.com OS: Linux 3.0.0-1-686-pae #1 SMP Sat Aug 27 16:41:03 UTC 2011 i686 GNU/Linux Distribution: Debian, several versions Window Maker 0.95.2 Best regards, Sergey Popov Sorry, I don't understand :-( I ran in a xterm: kix@osaka:~$ gvim --servername qwe .gvimrc Right click on the window title, maximize. alt+tab to return to the xterm OR mimimize the the window. kix@osaka:~$ gvim --servername qwe --remote-silent .gvimrc I have only one gvim window (the first). If the window was minimized, the command re-maximize it. If I make right click, I see UnMaximize option (the window is still maximized). I'm doing something wrong? Cheers, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/8] WindowMaker icon.c clean
On 08/03/12 23:01, Carlos R. Mafra wrote:
On Wed, 7 Mar 2012 at 1:15:46 +0100, Rodolfo García Peñas wrote:
Subject: [PATCH 3/8] WindowMaker icon.c clean
This commit clean the source.
---
src/icon.c | 50 ++
1 files changed, 22 insertions(+), 28 deletions(-)
diff --git a/src/icon.c b/src/icon.c
index be1b3a7..92c390a 100644
--- a/src/icon.c
+++ b/src/icon.c
@@ -281,31 +281,29 @@ static Pixmap makeIcon(WScreen *scr, RImage *icon, int
titled, int shadowed, int
Pixmap pixmap;
int x, y, sx, sy;
unsigned w, h;
-int theight = WMFontHeight(scr-icon_title_font);
+int theight = 0;
-if (tileType == TILE_NORMAL)
+if (tileType == TILE_NORMAL) {
tile = RCloneImage(scr-icon_tile);
-else {
+} else {
assert(scr-clip_tile);
tile = RCloneImage(scr-clip_tile);
}
+
if (icon) {
w = (icon-width wPreferences.icon_size)
? wPreferences.icon_size : icon-width;
x = (wPreferences.icon_size - w) / 2;
sx = (icon-width - w) / 2;
-if (!titled) {
-h = (icon-height wPreferences.icon_size)
-? wPreferences.icon_size : icon-height;
-y = (wPreferences.icon_size - h) / 2;
-sy = (icon-height - h) / 2;
-} else {
-h = (icon-height + theight wPreferences.icon_size
- ? wPreferences.icon_size - theight : icon-height);
-y = theight + ((int)wPreferences.icon_size - theight -
h) / 2;
-sy = (icon-height - h) / 2;
-}
+if (titled)
+theight = WMFontHeight(scr-icon_title_font);
+
+h = (icon-height + theight wPreferences.icon_size
+ ? wPreferences.icon_size - theight : icon-height);
+y = theight + ((int)wPreferences.icon_size - theight - h) / 2;
+sy = (icon-height - h) / 2;
+
Cool.
But you should drop the (int) cast because icon_size is already of
int type.
Ok :-)
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Removing net_icon_image
El 07.03.2012 18:25, Carlos R. Mafra escribió: On Wed, 7 Mar 2012 at 1:13:56 +0100, Rodolfo García Peñas wrote: I am trying to remove the var net_icon_image. We don't need it, because we have WIcon in the WWindow struct. To do it, and understand why I am doing this, I need to clean some parts of icon.c and wmspec.c files. I will attach 8 patches only with clean, re-ordering, and spliting functions. The code is just the same that before the patches, but now, is more clear. Please, take care with the last patch, because I found that one variable is not freeded (but I am so tired and I prefer to add a FIXME label only). Tomorrow, If I have time, I will send more patches, but, please, apply these. This week I'm mostly offline because I'm in another city for a workshop. Therefore I won't have time to review this set until next week, and I won't apply it till then. So if people have comments please come forward now. And you'll probably have the extra time to think about the FIXME :-) Enjoy your week and #include beer.h :-) -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WindowMaker: Tech+opaque resize
El 05.03.2012 00:32, Carlos R. Mafra escribió: On Sun, 4 Mar 2012 at 17:31:52 +0100, Rodolfo García Peñas wrote: Subject: [PATCH] WindowMaker: Tech+opaque resize This patch solves a problem when the user set technical and opaque flags and then resize the window. The pach also removes some curly brackets and make some if-else easier. Thanks for the patch! :-) But please, don't mix cleanups with bug fixes. If you want to clean the style a bit (which is nice) you should write the cleanup patch first doing just the cleanup. Then you write the smaller bug fix, trying to explain in the message what happened etc. It makes reviewing much easier. I know, sorry. The problem is that to understand the code, I rewrote (cleanup) some parts,... The patch is not in the git, do you need that I rewrite the patches? About that idea, in the commit http://repo.or.cz/w/wmaker-crm.git/commit/a3c99bddc891cbd4cae233421920b83acc733186 I sent two patches, but you uploaded only one (rebased). The reason was that the clean file is not a menu part. If we need to do a revert, we need to remember it. Anyway, thanks a lot for the uploads and for your comments. Best Regards++, kix PS. I am thinking to change my signature to something like WindowMaker needs a BTS :-P In any case, thanks a lot for fixing the bug! --- [snip] -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] WindowMaker: Tech+opaque resize
El 05.03.2012 17:32, Carlos R. Mafra escribió: On Mon, 5 Mar 2012 at 12:00:24 +0200, Rodolfo kix Garcia wrote: El 05.03.2012 00:32, Carlos R. Mafra escribió: On Sun, 4 Mar 2012 at 17:31:52 +0100, Rodolfo García Peñas wrote: Subject: [PATCH] WindowMaker: Tech+opaque resize This patch solves a problem when the user set technical and opaque flags and then resize the window. The pach also removes some curly brackets and make some if-else easier. Thanks for the patch! :-) But please, don't mix cleanups with bug fixes. If you want to clean the style a bit (which is nice) you should write the cleanup patch first doing just the cleanup. Then you write the smaller bug fix, trying to explain in the message what happened etc. It makes reviewing much easier. I know, sorry. The problem is that to understand the code, I rewrote (cleanup) some parts,... The patch is not in the git, do you need that I rewrite the patches? I'll upload it as-is, no need to rewrite anything. I just wanted to raise the issue. Ok, no problem. In this way, in the future, probably I will split some patches in various, to better understanding. After, you can rebase it if you want to upload them. About that idea, in the commit http://repo.or.cz/w/wmaker-crm.git/commit/a3c99bddc891cbd4cae233421920b83acc733186 I sent two patches, but you uploaded only one (rebased). The reason was that the clean file is not a menu part. If we need to do a revert, we need to remember it. The reason I rebased is that I don't think that debian-specific commits should have any granularity as they are not really pertinent to wmaker development per se, so they should be as invisible as possible. Ok, no problem I will send the patches splitted to better understanding. You can rebase it to upload. If the patches are easy to understand, then I will send as only one patch. Thanks. kix. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Options for limiting window/menu title height
On Mon, 27 Feb 2012 16:26:10 +0400, Alexey I. Froloff wrote:
On Mon, Feb 27, 2012 at 12:14:24PM +, Carlos R. Mafra wrote:
Thanks for the patch, but it doesn't apply because it gets mangled
by
the email server (or because you are using pgp)
Sending it attached should do the trick.
OK. I'lll send it without commit message because this not a
single commit.
because if is not a function (so you need a space after it) and
the
convention is to have the statement on a new line.
Sure. Should I add empty lines around these ifs?
if (flags WFF_TITLEBAR) {
theight = WMFontHeight(*fwin-font) + (*fwin-title_clearance
+ TITLEBAR_EXTEND_SPACE) * 2;
if(theight *fwin-title_max_height)
theight = *fwin-title_max_height;
if(theight *fwin-title_min_height)
theight = *fwin-title_min_height;
} else
vs.
if (flags WFF_TITLEBAR) {
theight = WMFontHeight(*fwin-font) + (*fwin-title_clearance
+ TITLEBAR_EXTEND_SPACE) * 2;
if(theight *fwin-title_max_height)
theight = *fwin-title_max_height;
if(theight *fwin-title_min_height)
theight = *fwin-title_min_height;
} else
?
IMO,
if (
not
if(
Cheers,
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: contributing: getting started
On Mon, 27 Feb 2012 14:38:59 +, Carlos R. Mafra wrote: On Sat, 25 Feb 2012 at 23:09:40 +, Nuno Donato wrote: Hi everyone, More than 8 years later, I got tired of the big desktop environments and found my way back to good old WMaker :) Happy to see that development is still going on! I subscribed to this list as I'm interested in contributing to the project, but there isn't much documentation/howtos for welcoming new contributors. You've just found a way to contribute. You can contribute by making the available documentation better! Or even creating new ones which you would like to have read when you made the comment above :-) See for example if the information on http://windowmaker.org/guide_toc.php is up-to-date (there are some parts which aren't) and modify it accordingly. Or you can help by converting the outside Guided Tour into the webpage format so that we can host that valuable information on windowmaker.org - right now that website seems to be down. You can also do that for the great WINGs tutorial, which now is also not hosted on windowmaker.org. The author of that tutorial released it under a free license, so we can do that. On that way, IMO the Changelog is more important. Setting up a updated changelog ASAP, is better to document for the users the new functionalities, patches,... We also need a BTS and take a look (update,...) the BUGS file. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Help with patch about icons
On Mon, 20 Feb 2012 08:55:45 +, Carlos R. Mafra wrote: On Mon, 20 Feb 2012 at 1:12:39 +0100, Rodolfo García Peñas wrote: The second patch is more insteresting. It removes the net_icon_image. Don't do it just like that. What if the application has a net_icon and no other icon? If the application has an icon in its binary, that should ideally be the best icon to use in all situations. I know. I want to use the same icon in the switchpanel and in the appdocks. If the application has a net_icon, this icon should be used in the switchpanel and in the appdocks. Therefore we should use the same functions in both places. Then, we should remove net_icon_image and add (if is needed) this stuff to the WIcon structure. If that is not working for the switchpanel for some reason we have to a) understand the reason and b) fix it. Yes, :-) this is the reason of my mail ;-) I don't see the problem, but the problem exists. I know of an annoying issue with evince about this, which is perhaps what you see too. The appicon is displayed correctly (it is the proper evince icon) but the icon in the swichpanel is not. I think that's because evince makes an icon with a preview of the file content to use as net_icon_image, but that doesn't show (I get the default appicon in the switchpanel) because I _guess_ wmaker is having troubles with the rather unusual size of the icon: Yes, the function calls for switchpanel and appdock are different, then the image is different too. _NET_WM_ICON(CARDINAL) =Icon (132 x 185): But in principle I don't see why this can't be fixed. Will it be better to have a preview icon instead of an evince icon? I don't know. But we should discuss that after fixing the issue first. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Call for helpers : wmauda
On 14/02/12 20:53, Renato Botelho wrote: wmauda 0.8 was released and can be found at: http://www.netswarm.net/ Regards Hi Renato, I sent a new version to the upstream. Is at dockapps too. Only one comment, probably there is a mistake in Makefile, because with the destination folder is /usr/local. If you have problems, please, change to /usr. Carlos discovered this problem. We will report it to upstream soon. I made the package for the debian distribution (is in unstable now), and the destination directory is /usr, therefore the problem don't affect. Cheers. On Thu, Feb 9, 2012 at 5:44 PM, Carlos R. Mafra crma...@gmail.com wrote: Cc:ing wmaker-dev On Tue, 31 Jan 2012 at 11:20:27 +0100, Cyril LAVIER wrote: Hi. I'm Cyril Lavier, the maintainer of audacious/audacious-plugins in Debian. Recently, we switched to the 3.2 release. But some programs stopped building/working since. So I have to find ways to make these programs work again. One of these is wmauda, a dockapp applet for windowmaker which controls audacious. I'm searching for helpers because Christian, the developer of this project (added in CC) doesn't have time to update it. So if you use windowmaker, audacious, you have free time and if you have skills in C developing. You can help keeping wmauda up to date and alive. In case somebody wants to help Christian, I accept to do the Debian part of the work, which is maintaining the package and asking for an upload in Debian Unstable. Also, there is a risk of Debian removing the package from Debian Unstable, as wmauda can't build anymore. Thanks. -- Cyril Davromaniak Lavier -- To unsubscribe, send mail to wmaker-user-unsubscr...@lists.windowmaker.org. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: WindowMaker 0.95.2 Released
On 14/02/12 21:55, Daniel Isenmann wrote: On Tue, 14 Feb 2012 11:59:49 -0800 John H. Robinson, IV jaq...@sbih.org wrote: The Window Maker Project is pleased to announce the latest stable release of Window Maker, 0.95.2. You can get the latest release from http://windowmaker.org/pub/source/release/WindowMaker-0.95.2.tar.gz I'll write up a proper release announcement, but I wanted -dev to know first. -john Great! Perfect news post in the evening, I have added it right now to the Arch Linux package repository. :) Yes! Thanks a lot. Runs perfectly, good work and thanks to all devs for this release. -Daniel -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [repo.or.cz] wmaker-crm.git branch master updated: wmaker-0.95.2-1-g854ae58
On 15/02/12 00:28, crmafra wrote: 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, master has been updated via 854ae5830572017d429a9d0c2d5215fca24f4447 (commit) from 87ce0de15fe02fe4d96d13cb46c7a352803d5126 (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/854ae5830572017d429a9d0c2d5215fca24f4447 commit 854ae5830572017d429a9d0c2d5215fca24f4447 Author: Rodolfo García Peñas (kix) k...@kix.es Date: Tue Feb 14 23:59:47 2012 +0100 debian: New debian version 0.95.2 New debian version 0.95.2 changelog file. This version closes these debian bugs: #69669, #486542, #270877, #283240, #48550, #297019, #108432, #72917. diff --git a/debian/changelog b/debian/changelog index 8bf7cb0..3cd8a59 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +wmaker (0.95.2) unstable; urgency=low + + * New upstream version 0.95.2 [Closes: #69669, #486542, #270877] +[Closes: #283240, #48550, #297019, #108432, #72917] + + -- Rodolfo García Peñas (kix) k...@kix.es Tue, 14 Feb 2012 23:58:45 +0100 + wmaker (0.95.1+20120131-1) unstable; urgency=low * New upstream version 0.95.1 [Closes: #304480] --- Summary of changes: debian/changelog |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) 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. Thanks. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH] WPrefs: PropList load rewrited
I was working in the WPrefs file.
This is only a ligth patch. The idea is break this big function in three
smaller, and reuse one of them.
I was thinking about WPrefs and src/Windowmaker.h and probably the should use
the same WPreferences structure. Now WPrefs reads the information from the
config file using a own function and WindowMaker do the same using other
function. I will try to join that.
WPrefs read the info and save it in a PropList
WindowMaker reads and save it in a wPreferences structure.
My idea is remove the proplists in WPrefs and make a readConf writeConf
(random names) functions. The functions and the structure will be in the
WindowMaker folder (src) and WPrefs will include it (#include ../src/xyz.h).
Comments?
kix
From 1edd5a8e4ff0fc4e8e731a4a33bcec88a27c1d5f Mon Sep 17 00:00:00 2001
From: Rodolfo García Peñas (kix) k...@kix.es
Date: Tue, 14 Feb 2012 20:06:43 +0100
Subject: [PATCH] WPrefs: PropList load rewrited
The load of the configuration PropLists are re-writed.
Now uses a new common function for the load, and includes a lot of comments.
---
WPrefs.app/WPrefs.c | 254 +++
1 files changed, 134 insertions(+), 120 deletions(-)
diff --git a/WPrefs.app/WPrefs.c b/WPrefs.app/WPrefs.c
index 2b69b51..6d63b55 100644
--- a/WPrefs.app/WPrefs.c
+++ b/WPrefs.app/WPrefs.c
@@ -95,8 +95,11 @@ static char *WindowMakerDBPath = NULL;
static Bool TIFFOK = False;
#define INITIALIZED_PANEL (10)
+/* Prototyples */
+WMPropList *loadConfigurationProplist(WMScreen *scr, WMWindow *mainw, char
*config_file);
+static void loadConfigurations(WMScreen *scr, WMWindow * mainw);
+char *get_global_filename(WMScreen *scr, WMWindow *mainw);
-static void loadConfigurations(WMScreen * scr, WMWindow * mainw);
static void savePanelData(Panel * panel);
@@ -638,125 +641,6 @@ WMWindow *GetWindow(Panel * panel)
return WPrefs.win;
}
-static void loadConfigurations(WMScreen * scr, WMWindow * mainw)
-{
- WMPropList *db, *gdb;
- char *path;
- FILE *file;
- char buffer[1024];
- char mbuf[1024];
- int v1, v2, v3;
-
- path = wdefaultspathfordomain(WindowMaker);
- WindowMakerDBPath = path;
-
- db = WMReadPropListFromFile(path);
- if (db) {
- if (!WMIsPLDictionary(db)) {
- WMReleasePropList(db);
- db = NULL;
- sprintf(mbuf, _(Window Maker domain (%s) is
corrupted!), path);
- WMRunAlertPanel(scr, mainw, _(Error), mbuf, _(OK),
NULL, NULL);
- }
- } else {
- sprintf(mbuf, _(Could not load Window Maker domain (%s) from
defaults database.), path);
- WMRunAlertPanel(scr, mainw, _(Error), mbuf, _(OK), NULL,
NULL);
- }
-
- path = getenv(WMAKER_BIN_NAME);
- if (!path)
- path = wmaker;
- {
- char *command;
-
- command = wstrconcat(path, --version);
- file = popen(command, r);
- wfree(command);
- }
- if (!file || !fgets(buffer, 1023, file)) {
- werror(_(could not extract version information from Window
Maker));
- wfatal(_(Make sure wmaker is in your search path.));
-
- WMRunAlertPanel(scr, mainw, _(Error),
- _
- (Could not extract version from Window Maker.
Make sure it is correctly installed and is in your PATH environment variable.),
- _(OK), NULL, NULL);
- exit(1);
- }
- if (file)
- pclose(file);
-
- if (sscanf(buffer, Window Maker %i.%i.%i, v1, v2, v3) != 3
-sscanf(buffer, WindowMaker %i.%i.%i, v1, v2, v3) != 3) {
- WMRunAlertPanel(scr, mainw, _(Error),
- _(Could not extract version from Window Maker.
- Make sure it is correctly installed and the
path
- where it installed is in the PATH
environment
- variable.), _(OK), NULL, NULL);
- exit(1);
- }
- if (v1 == 0 (v2 18 || v3 0)) {
- sprintf(mbuf, _(WPrefs only supports Window Maker 0.18.0 or
newer.\n
- The version installed is %i.%i.%i\n), v1, v2,
v3);
- WMRunAlertPanel(scr, mainw, _(Error), mbuf, _(OK), NULL,
NULL);
- exit(1);
-
- }
- if (v1 1 || (v1 == 1 (v2 0))) {
- sprintf(mbuf,
- _
- (Window Maker %i.%i.%i, which is installed in your
system, is not fully supported by this version of WPrefs.),
- v1, v2, v3);
- WMRunAlertPanel(scr, mainw, _(Warning), mbuf, _(OK), NULL,
NULL);
- }
-
- {
- char *command;
-
-
Re: [PATCH] Remove dead code ifdef'ed by GRADIENT_CLIP_ARROW
On 11/02/12 20:10, Carlos R. Mafra wrote: GRADIENT_CLIP_ARROW was never defined anywhere and having fancier clip arrows is not something particularly interesting, so let's simply remove the code. [snip] I tried ./configure -DGRADIENT_CLIP_ARROW and no differences in the clip. IMO the code is not needed. Thanks for the patch. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] clip: Do not display balloon with workspace name
On 11/02/12 23:03, Carlos R. Mafra wrote:
On Sat, 11 Feb 2012 at 21:16:34 +, Carlos R. Mafra wrote:
Subject: [PATCH] clip: Do not display balloon with workspace name
Oh, I see now.
This balloon can be slightly useful if the clip is already displaying
the workspace name. If the name does not fit into the clip icon it is
drastically cut at the boundary, and then moving the mouse over the
clip completes the name by writing the missing piece -- which is
the odd thing I saw earlier, and it is odd because my clip was not
displaying the workspace name.
So another less disrupting option would be to display the balloon
only if show_clip_title is set via WPrefs, something like the patch
below.
But I find this behavior of completing the name a workaround for
a ugly situation. Having the name cut does not look beautiful, and
I see little aesthetic improvement by completing it like that.
Does anybody who hasn't already shortened the workspace name
like this balloon completion? I think the code removal for this
dubious situation is better than the patch below. And perhaps
another patch to not display a name which does not fit would
also be appropriate.
Comments?
Yes, first, very good job. Second, IMO you can apply the previous patch to
remove the odd label. Then, you can apply the patch attached. This patch show
the Clip's name if the length of the label is 5 characters in a normal
balloon. If you want, can remove the length 5 and the name will be show
always, but in my opinion the info is redundant.
The patch clean some brackets and empty lines. This is the patch:
From fe9b47ed12bd1e107abd7708ed8c0adfff00ab7f Mon Sep 17 00:00:00 2001
From: Rodolfo García Peñas (kix) k...@kix.es
Date: Sun, 12 Feb 2012 16:08:51 +0100
Subject: [PATCH] WindowMaker: Add Balloon to the clip
Now the clip has balloon if dock icon is set in WMPrefs.
---
src/balloon.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/src/balloon.c b/src/balloon.c
index a4e8aaf..23ca21f 100644
--- a/src/balloon.c
+++ b/src/balloon.c
@@ -439,7 +439,15 @@ static void appiconBalloon(WObjDescriptor * object)
WScreen *scr = aicon-icon-core-screen_ptr;
char *tmp;
- if (aicon-command aicon-wm_class) {
+ /* If is the Clip and the length of the workspace's name is 6, then
show the ballon */
+ if (object-parent == scr-clip_icon) {
+ if (strlen(scr-workspaces[scr-current_workspace]-name) 5) {
+ scr-balloon-text =
wstrdup(scr-workspaces[scr-current_workspace]-name);
+ } else {
+ wBalloonHide(scr);
+ return;
+ }
+ } else if (aicon-command aicon-wm_class) {
int len = strlen(aicon-command) + strlen(aicon-wm_class) + 8;
tmp = wmalloc(len);
snprintf(tmp, len, %s\n(%s), aicon-wm_class, aicon-command);
@@ -510,24 +518,19 @@ void wBalloonEnteredObject(WScreen * scr, WObjDescriptor
* object)
balloon-ignoreTimer = 0;
return;
}
+
switch (object-parent_type) {
case WCLASS_FRAME:
- if (wPreferences.window_balloon) {
+ if (wPreferences.window_balloon)
frameBalloon(object);
- }
break;
-
case WCLASS_DOCK_ICON:
- if (object-parent != scr-clip_icon
wPreferences.appicon_balloon)
+ if (wPreferences.appicon_balloon)
appiconBalloon(object);
- else
- wBalloonHide(scr);
break;
-
case WCLASS_MINIWINDOW:
- if (wPreferences.miniwin_balloon) {
+ if (wPreferences.miniwin_balloon)
miniwindowBalloon(object);
- }
break;
case WCLASS_APPICON:
if (wPreferences.appicon_balloon)
--
1.7.7.3
[snip]
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
From fe9b47ed12bd1e107abd7708ed8c0adfff00ab7f Mon Sep 17 00:00:00 2001
From: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Sun, 12 Feb 2012 16:08:51 +0100
Subject: [PATCH] WindowMaker: Add Balloon to the clip
Now the clip has balloon if dock icon is set in WMPrefs.
---
src/balloon.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/src/balloon.c b/src/balloon.c
index a4e8aaf..23ca21f 100644
--- a/src/balloon.c
+++ b/src/balloon.c
@@ -439,7 +439,15 @@ static void appiconBalloon(WObjDescriptor * object)
WScreen *scr = aicon-icon-core-screen_ptr;
char *tmp;
- if (aicon-command aicon-wm_class) {
+ /* If is the Clip and the length of the workspace's name is 6, then show the ballon */
+ if (object-parent == scr-clip_icon) {
+ if (strlen(scr-workspaces[scr-current_workspace]-name) 5) {
+ scr-balloon-text = wstrdup(scr-workspaces
[PATCH] WindowMaker: removed OpenWorkspaceMenu
From bd7ca98fd410d3eab84ef69a2fc62490d7389533 Mon Sep 17 00:00:00 2001
From: Rodolfo García Peñas (kix) k...@kix.es
Date: Sun, 12 Feb 2012 20:04:50 +0100
Subject: [PATCH] WindowMaker: removed OpenWorkspaceMenu
The function OpenWorkspaceMenu is not used, so can be removed.
---
src/funcs.h |2 --
src/menu.c | 33 -
2 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/src/funcs.h b/src/funcs.h
index 5d813ea..6d2c552 100644
--- a/src/funcs.h
+++ b/src/funcs.h
@@ -61,8 +61,6 @@ void OpenWindowMenu2(WWindow *wwin, int x, int y, int
keyboard);
void OpenMiniwindowMenu(WWindow *wwin, int x, int y);
-void OpenWorkspaceMenu(WScreen *scr, int x, int y);
-
void CloseWindowMenu(WScreen *scr);
void DestroyWindowMenu(WScreen *scr);
diff --git a/src/menu.c b/src/menu.c
index dd84ca2..ecbd6a6 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -2495,36 +2495,3 @@ void wMenuRestoreState(WScreen * scr)
}
restoreMenuRecurs(scr, menus, scr-root_menu, );
}
-
-void OpenWorkspaceMenu(WScreen * scr, int x, int y)
-{
- WMenu *menu, *parent;
- WMenuEntry *entry;
-
- if (!scr-root_menu) {
- OpenRootMenu(scr, scr-scr_width * 2, 0, False);
- wMenuUnmap(scr-root_menu);
- }
-
- menu = scr-workspace_menu;
- if (menu) {
- if (menu-flags.mapped) {
- if (!menu-flags.buttoned) {
- wMenuUnmap(menu);
- parent = menu-parent;
- if (parent parent-selected_entry = 0) {
- entry =
parent-entries[parent-selected_entry];
- if (parent-cascades[entry-cascade] ==
menu) {
- selectEntry(parent, -1);
- wMenuMapAt(menu, x, y, False);
- }
- }
- } else {
- wRaiseFrame(menu-frame-core);
- wMenuMapCopyAt(menu, x, y);
- }
- } else {
- wMenuMapAt(menu, x, y, False);
- }
- }
-}
--
1.7.7.3
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
From bd7ca98fd410d3eab84ef69a2fc62490d7389533 Mon Sep 17 00:00:00 2001
From: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Sun, 12 Feb 2012 20:04:50 +0100
Subject: [PATCH] WindowMaker: removed OpenWorkspaceMenu
The function OpenWorkspaceMenu is not used, so can be removed.
---
src/funcs.h |2 --
src/menu.c | 33 -
2 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/src/funcs.h b/src/funcs.h
index 5d813ea..6d2c552 100644
--- a/src/funcs.h
+++ b/src/funcs.h
@@ -61,8 +61,6 @@ void OpenWindowMenu2(WWindow *wwin, int x, int y, int keyboard);
void OpenMiniwindowMenu(WWindow *wwin, int x, int y);
-void OpenWorkspaceMenu(WScreen *scr, int x, int y);
-
void CloseWindowMenu(WScreen *scr);
void DestroyWindowMenu(WScreen *scr);
diff --git a/src/menu.c b/src/menu.c
index dd84ca2..ecbd6a6 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -2495,36 +2495,3 @@ void wMenuRestoreState(WScreen * scr)
}
restoreMenuRecurs(scr, menus, scr-root_menu, );
}
-
-void OpenWorkspaceMenu(WScreen * scr, int x, int y)
-{
- WMenu *menu, *parent;
- WMenuEntry *entry;
-
- if (!scr-root_menu) {
- OpenRootMenu(scr, scr-scr_width * 2, 0, False);
- wMenuUnmap(scr-root_menu);
- }
-
- menu = scr-workspace_menu;
- if (menu) {
- if (menu-flags.mapped) {
- if (!menu-flags.buttoned) {
-wMenuUnmap(menu);
-parent = menu-parent;
-if (parent parent-selected_entry = 0) {
- entry = parent-entries[parent-selected_entry];
- if (parent-cascades[entry-cascade] == menu) {
- selectEntry(parent, -1);
- wMenuMapAt(menu, x, y, False);
- }
-}
- } else {
-wRaiseFrame(menu-frame-core);
-wMenuMapCopyAt(menu, x, y);
- }
- } else {
- wMenuMapAt(menu, x, y, False);
- }
- }
-}
--
1.7.7.3
Re: Call for helpers : wmauda
On 09/02/12 20:44, Carlos R. Mafra wrote: Cc:ing wmaker-dev On Tue, 31 Jan 2012 at 11:20:27 +0100, Cyril LAVIER wrote: Hi. I'm Cyril Lavier, the maintainer of audacious/audacious-plugins in Debian. Recently, we switched to the 3.2 release. But some programs stopped building/working since. So I have to find ways to make these programs work again. One of these is wmauda, a dockapp applet for windowmaker which controls audacious. I'm searching for helpers because Christian, the developer of this project (added in CC) doesn't have time to update it. So if you use windowmaker, audacious, you have free time and if you have skills in C developing. You can help keeping wmauda up to date and alive. In case somebody wants to help Christian, I accept to do the Debian part of the work, which is maintaining the package and asking for an upload in Debian Unstable. Also, there is a risk of Debian removing the package from Debian Unstable, as wmauda can't build anymore. Thanks. -- Cyril Davromaniak Lavier -- To unsubscribe, send mail to wmaker-user-unsubscr...@lists.windowmaker.org. Hi Cyril, I am trying to maintain wmauda in debian. I know the problem, the package is ITA but have problems with some functions removed in the last version. I contacted with the developer of audacious, the libraries were removed because are not used. He don't seem to revert the changes. I sent an email to the upstream developer of wmauda, but not reply. If we have no reply is some days, I will upload the package to someplace (probably our dockapps repo if Carlos don't have problems), and I will made the changes. I am not sure about the changes I need to do to solve the problems. I hadn't time to review the source code of wmauda. Your help is welcome. Best Regards, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
wmakerconf removed from debian
Hi, for your information, the package wmakerconf has been removed from Debian, because it don't have upstream developer. More info here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658698 Regards, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Call for helpers : wmauda
On 09/02/12 22:39, Cyril Lavier wrote: On 02/09/2012 09:58 PM, Rodolfo kix Garcia wrote: On 09/02/12 20:44, Carlos R. Mafra wrote: [snip] I opened a bug : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657596 Ok, thanks. Maybe we can use it to coordinate our efforts in resolving the issues appeared with the upgrade of audacious. I sent an email to the upstream developer of wmauda, but not reply. If we have no reply is some days, I will upload the package to someplace (probably our dockapps repo if Carlos don't have problems), and I will made the changes. You sent a mail to Christian Birchinger ? Yes, Chistian, George Averill and Michael Steward (mail address don't exists). No reply. If you wrote him too, probably is MIA. I am not sure about the changes I need to do to solve the problems. I hadn't time to review the source code of wmauda. Your help is welcome. I'm trying to find people to help for wmauda because I think it's one of my responsibilities on being the maintainer of audacious/audacious-plugins packages, to help people resolving FTBFS when upgrading a package. The only help I can give in this case, it's finding a sponsor for the updated package (maybe the sponsor for audacious packages will agree on sponsoring yours), and heavily testing the builds. Because I don't use windowmaker, and the last time I fully wrote a C program was 6 years ago, when I was in college ^^. No problem, I have a Sponsor and is a very good sponsor. I am so happy with him. He tested the package and is waiting now for the solution to the problem and my new upload. Thanks a lot anyway. I will contact with you soon with a solution. On the other hand, try Window Maker ;-) Cheers, kix Best Regards, kix Thanks. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: BTS
On Sun, 05 Feb 2012 15:02:56 -0800, Doug Barton wrote: On 02/05/2012 07:48, Martin Dietze wrote: I suggest we move the project to sourceforge. Getting the project approved will be no problem. Sourceforge does git hosting, and it has TRAC. I have some of my projects hosted by them, and I have no reasons for complaints. The only thing that is missing right now is git integration in TRAC. They've promised to get this done for long, and so far it hasn't happened. But even without git integration TRAC is a fair bug tracking sysem. This way we'd have the stuff hosted, also if Carlos wants, he can easily add more developers with repository write acces. This makes a lot of sense to me. The idea is good, but, SourceForge (and google code) has countries blocked. We should close the BTS topic :-) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: BTS
On Tue, 7 Feb 2012 11:43:55 +0100, Martin Dietze wrote: On Tue, February 07, 2012, Rodolfo kix Garcia wrote: The idea is good, but, SourceForge (and google code) has countries blocked. That's interesting, I did not know that. Which countries, and for what reason? Cuba, Iran, North Korea, Sudan, Syria http://geek.net/terms-of-use#ProhibitedPersons If that is a blocker (I can't comment on that without more information), maybe there's another good open source hoster around with bug tracker integration? I still think that SF is a good choice.. No problem for me. Cheers, kix Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= I got it good, I got it bad. I got the sweetest sadness I ever had. --- the The -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re-Redeveloped Website
;
}
-# a:visited, a:active {
-# text-decoration: underline;
-# color: #FFF;
-#}
+
img {
border: none;
}
-#header { position: relative; top: 0px; left: 6%;
- width: 100%; }
-#dock { position: absolute; top: 150px; left: 5px;
- width: 100%; height: 500px;
- }
+#header {
+ font-family: American Typewriter, Courier, monospace;
+ font-size: 4.5em;
+ font-weight: normal;
+ position: absolute; top: 0px; left: 100px;
+}
-#inhalt { position: relative; top: 10px; left: 10%;
- width: 100%;
- }
+#dock {
+ position: absolute; top: 100px; left: 5px;
+}
-#tableline {
-color: #F00;
+#inhalt {
+ position: absolute; top: 110px; left: 100px;
+ width: 70%;
}
--
1.7.7.3
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
From 3e926515415fbbde3432302b739e274ed2c73798 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20(kix)?= k...@kix.es
Date: Sun, 5 Feb 2012 16:09:51 +0100
Subject: [PATCH] Width tags clean
Removed the body and header tags of these pages, because when are joined by php the final document will have three times the body and the header tags included.
Removed the width tags, to avoid the space in the right side and the horizontal slide.
Removed the homewmaker2.png link image, because this text can be made using formatted text.
Removed a lot of \n \r.
---
dock.php | 28 --
header.php | 16 ++
index.php | 12 +++---
main.php | 40 +++---
title.css | 61 ++-
5 files changed, 59 insertions(+), 98 deletions(-)
diff --git a/dock.php b/dock.php
index 29f0a0f..ffe56c3 100644
--- a/dock.php
+++ b/dock.php
@@ -1,41 +1,23 @@
-html
-head
- meta name=generator content=HTML Tidy for Linux (vers 25 March 2009), see www.w3.org
-
- title/title
-/head
-
-body
div id=dock
table width=64 height=500 border=0 cellpadding=0 cellspacing=0
tr
-tda href=home.php onmouseout=MM_swapImgRestore() onmouseover=
-MM_swapImage('Image1','','homewmaker.png',0)img src=homewmaker.png alt=Home width=60 height=81 border=0 id=
-Image1/a/td
+tda href=home.php onmouseout=MM_swapImgRestore() onmouseover=MM_swapImage('Image1','','homewmaker.png',0)img src=homewmaker.png alt=Home width=60 height=81/a/td
/tr
tr
-tda href=news.php onmouseout=MM_swapImgRestore() onmouseover=MM_swapImage('Image2','','news.png',0)img src=
-news.png alt=News width=60 height=81 border=0 id=Image2/a/td
+tda href=news.php onmouseout=MM_swapImgRestore() onmouseover=MM_swapImage('Image2','','news.png',0)img src=news.png alt=News width=60 height=81/a/td
/tr
tr
-tda href=docs.php onmouseout=MM_swapImgRestore() onmouseover=MM_swapImage('Image3','','docs.png',0)img src=
-docs.png alt=Documentation width=60 height=81 border=0 id=Image3/a/td
+tda href=docs.php onmouseout=MM_swapImgRestore() onmouseover=MM_swapImage('Image3','','docs.png',0)img src=docs.png alt=Documentation width=60 height=81/a/td
/tr
tr
-tda href=lists.php onmouseout=MM_swapImgRestore() onmouseover=
-MM_swapImage('Image4','','mailing_list.png',0)img src=mailing_list.png alt=Mailing Lists width=60 height=81
-border=0 id=Image4/a/td
+tda href=lists.php onmouseout=MM_swapImgRestore() onmouseover=MM_swapImage('Image4','','mailing_list.png',0)img src=mailing_list.png alt=Mailing Lists width=60 height=81/a/td
/tr
tr
-tda href=dev.php onmouseout=MM_swapImgRestore() onmouseover=
-MM_swapImage('Image5','','development.png',0)img src=development.png alt=Development width=60 height=81
-border=0 id=Image5/a/td
+tda href=dev.php onmouseout=MM_swapImgRestore() onmouseover=MM_swapImage('Image5','','development.png',0)img src=development.png alt=Development width=60 height=81/a/td
/tr
/table
/div
-/body
-/html
diff --git a/header.php b/header.php
index 6046cf0..2cc4813 100644
--- a/header.php
+++ b/header.php
@@ -1,13 +1,3 @@
-!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN
-
-html
-head
- meta name=generator content=HTML Tidy for Linux (vers 25 March 2009), see www.w3.org
-
- titleWindow Maker homepage/title
-/head
-
-body
- div id=headerimg src=homewmaker2.png width=1100 height=110 style=border-bottom: #FFF alt=/div
-/body
-/html
+ div id=header
+Window Maker Home
+ /div
diff --git a/index.php b/index.php
index 734ec28..20803b0 100644
--- a/index.php
+++ b/index.php
@@ -2,15 +2,19 @@
html
head
- meta name=generator content=HTML Tidy for Linux (vers 25 March 2009), see www.w3.org
- meta http-equiv=Content-Type content=text/html; charset=us-ascii
+ meta name=generator content=vim :-)
+ meta http-equiv=Content-Type content=text/html; charset=UTF-8
titleWindow Maker - A window manager for X/title
- meta name=Keywords
[PATCH] WindowMaker: Support for icons from .desktop files
Hi,
some days ago I took a look in the WMLive CD structure. I found a lot of icons
(more than 1000), used to show the icon for an application. IMO this is an
error, because is not possible to have all the icons in the WindowMaker
folders. Some of the icons was multiple times, with different names, new
applications don't have icon (yes, default.xpm), we need maintain the config
files only for the icons,...
Then, I spent some time and found one solution. I was reading
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
and this is a patch to support .desktop files. These files are usually in
/usr/share/applications/appname.desktop and a reference to the Icon is included
in the file.
Now, we don't need modify the config file to setup the icon. We don't need a
lot of icons in the WindowMaker folders (less disk usage, less package size).
Please, send comments to the list about this patch before apply it in the git.
Testers are welcome. You need select an application without icon configured. If
the icon is selected in a config file, this patch is not used.
Best Regards,
kix
From 80b048ee3aeb57c023c9435e647bcd060cf5dcd6 Mon Sep 17 00:00:00 2001
From: Rodolfo García Peñas (kix) k...@kix.es
Date: Fri, 3 Feb 2012 13:01:35 +0100
Subject: [PATCH] WindowMaker: Support for icons from .desktop files
Most applications includes a .desktop file with information about them. This
files are like this:
$ cat /usr/share/applications/ddd.desktop
[Desktop Entry]
[snip]
Icon=ddd
These files include an icon name for the application, and normaly the icon is
installed with the application package.
This patch permits to read icons from the .desktop files. With this patch a lot
of icons of the WindowMaker package are not needed (save disk space and package
size), and the configuration files don't need to maintain information about
icon files.
The WindowMaker flow is the same as usual. Only when an icon is not found,
before select the default icon, a search for the .desktop info is done. If the
search found an icon, is selected. If the search fail, then the default icon is
set.
---
src/Makefile.am |2 +
src/desktop_entry.c | 257 +++
src/desktop_entry.h | 25 +
src/wdefaults.c | 13 ++-
4 files changed, 294 insertions(+), 3 deletions(-)
create mode 100644 src/desktop_entry.c
create mode 100644 src/desktop_entry.h
diff --git a/src/Makefile.am b/src/Makefile.am
index 0521d11..5d00bf5 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -26,6 +26,8 @@ wmaker_SOURCES = \
def_pixmaps.h \
defaults.c \
defaults.h \
+ desktop_entry.c \
+ desktop_entry.h \
dialog.c \
dialog.h \
dock.c \
diff --git a/src/desktop_entry.c b/src/desktop_entry.c
new file mode 100644
index 000..4f9e9fc
--- /dev/null
+++ b/src/desktop_entry.c
@@ -0,0 +1,257 @@
+/* desktop_entry.c - Some stuff from free desktop
+ *
+ * Window Maker window manager
+ *
+ * Copyright (c) 2012 Rodolfo kix García Peñas
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include ctype.h
+#include sys/types.h
+#include sys/stat.h
+
+#include WINGs/WUtil.h
+#include wconfig.h
+#include desktop_entry.h
+
+/* Returns the icon file patch from a .desktop file */
+WMPropList *get_iconpath_from_desktop_file(char *classe)
+{
+ char *dtf, *icn, *fcn;
+ WMPropList *ret;
+
+ /* First, search the .desktop file */
+ dtf = get_desktop_file(classe);
+
+ /* Now, get the iconfile named in the .desktop file */
+ icn = get_iconname_from_desktopfile(dtf);
+ wfree(dtf);
+
+ /* Test if the file exists */
+ fcn = get_correct_path(icn);
+ wfree(icn);
+
+ if (!fcn)
+ return NULL;
+
+ ret = WMCreatePLString(fcn);
+ wfree(fcn);
+
+ return ret;
+}
+
+/* This function returns the .desktop filename for a application class */
+char *get_desktop_file(char *classe)
+{
+ char *oclass, *desktopfile;
+ int i;
+
+ if (!classe)
+ return NULL;
+
+ oclass = wmalloc(strlen(classe) + 1);
+ sprintf(oclass, %s, classe);
+
+ /*
Re: WMLive CD/DVD ISO updated
On 31/01/12 18:43, Paul Seelig wrote: Hi Rodolfo, On 01/31/2012 06:01 PM, Rodolfo kix Garcia wrote: ... $ ls -Gg wmlive-create_0.46.tar.* -rw-rw-r-- 1 13709860 Jan 31 18:17 wmlive-create_0.46.tar.bz2 -rw-rw-r-- 1 13778636 Jan 31 18:05 wmlive-create_0.46.tar.gz -rw-r--r-- 1 12524768 Jan 31 17:40 wmlive-create_0.46.tar.xz $ dpkg -S $(which unxz) $(which xz) xz-utils: /usr/bin/unxz xz-utils: /usr/bin/xz In debian/unstable even my favorite file manager Midnight Commander is able to handle xzipped tar archives. We should start to get used to it, so that it finally becomes yet another standard. ) Ok, is only my oppinion. I will try to help with the size of your file, see below ;-) 2. Is possible to add your menu scripts in the windowmaker upstream or debian/ubuntu packages? If it is of any use, please just go ahead. The main script is BTW not really written by myself, but is an adapted/reused script from Arch Linux, which was adapted/reused from SuSE Linux, etc. I will try to take a look on it. Merry code go round! :) 3. Why not add all these stuff (themes,...) in one place at upstream/package? I guess in the long run this would be very good, but i am unsure if it really is a good idea to stuff everything and the kitchen sink into the upstream sources. This is an easy path to lose focus and orientation. Comments below. I was thinking about the menu system, if is better for you, probably is better for more people. I will try to take a look, and if is better, we can work to add it to the upstream or debian/ubuntu. Some informed cherry picking would probably be the best approach. Unfortunately i do not understand this code very well, so i didn't dare to modify it more than necessary to make it work. I will try to understand it. Regards Paul Thanks Paul. Comments: wmlive-data: - There are a lot of icons in /usr/share/WindowMaker/Icons. Probably is better move these icons to upstream. The icons wich are already in the package wm-icons should not be included (in the debian package) to avoid conflicts. - Theme. Probably we can add themes in any place in upstream. This is not the main task of the wmaker-git, but could put themes in some place. Then is possible to add a wmaker-themes package if needed. - The environments tgz files are using /usr/local instead /usr. I didn't review it, but what are the differences with the standard wmaker config files? Is possible to set the configuration for all environments together and then switch between them using a variable? wmlive-extra: - No comments, are only packages. wmlive-pkglists: - You are using ubuntu repos, bad ;-) [joke] wmlive-wmconfig: - You are using /usr/local - You are writing things in /var ? - I will review the menú system. In general, there are many config files that you are setting up. Probably is better to include these config files in the orignal packages (at /usr/share/doc/package/config.example or something like) and then copy the file to the user config folder. Probably is better to include things in the orignal packages or create a new packages. Coping files directly (without package manager), and using /usr/local seems to be a bad idea. Best Regards, kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: BTS
On 02/02/12 19:09, John H. Robinson, IV wrote: Rodolfo kix Garcia wrote: What do you think about install bugzilla? http://www.bugzilla.org/docs/tip/en/html/installation.html I hate bugzilla. XDD That said, I can host a bugzilla instance. N! I said bugzilla to say something. Bugzilla is well known, but if you want other, you are welcome. Though, to be completely honest, I think I'd rather see something like Trac or Redmine where everything is coordinated. Still requires pretty CSS. Ok, I don't have any preference. RFC in the mail list. -john kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re-Redeveloped Website
I don't like frames too. On 02/02/12 22:13, Paul Harris wrote: My review: I prefer the simpler look, but you'll have to start again with the actual build of the website. It uses frames, which is very bad in terms of navigation (eg, you can't click the News button, and then bookmark the site, because the URL doesn't change at the top), The frame sizing is all wrong on my Windows Chrome (buttons clipped etc), And if the window is shorter than the required height for the buttons frame, no scrollbar appears for scrolling down the buttons-frame. I tested the website on my little phone-browser, and each time I click a button, the content moves further to the right. So, I like the approach, but please switched to a frameless design. And, someone is going to have to put content up regularly (ie new News) On 3 February 2012 02:12, John H. Robinson, IV jaq...@sbih.org mailto:jaq...@sbih.org wrote: I think we[1] can all agree that the Mojomojo experiment is a dismal failure. With that in mind, I'd like to present a simpler, more NeXTish website. Carlos took some time to write up a rather simple interface that shows off some of the best clean features and navigations of Window Maker. http://beta.windowmaker.org/ Feel free to take a look around, and comment. If this is good, a git repo will be set up and we can have at. -- John H. Robinson, IV jaq...@sbih.org mailto:jaq...@sbih.org http WARNING: I cannot be held responsible for the above, sbih.org http://sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html [1] I speak only for myself, and those that like what I say. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org mailto:wmaker-dev-unsubscr...@lists.windowmaker.org. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Debian Build error in the git
On Wed, 1 Feb 2012 14:53:02 +, Carlos R. Mafra wrote: On Wed, 1 Feb 2012 at 15:47:23 +0100, Martin Dietze wrote: - copy_file@Base 0.95.1 +#MISSING: 0.95.1-git-20120201-1459-1# copy_file@Base 0.95.1 destroyNode@Base 0.95.0 + wcopy_file@Base 0.95.1-git-20120201-1459-1 Right, Rodolfo suggested to rename the too-general name copy_file() because it was causing clashes with wmakerconf, so I renamed it to wcopy_file(). But I guess the debian folder has to be updated to reflect that, but I didn't look at that. Rodolfo? Yes? Ah! other debian problem ;-) Yes, yesterday I made a new debian package to upload to the debian distro. I was tired and didn't make the patch for the debian folder in upstream. Sorry. I can do the patch this evening. If you want to do it, please, download the new debian folder from: http://mentors.debian.net/debian/pool/main/w/wmaker/wmaker_0.95.1+20120131-1.debian.tar.gz Uncompress it and make a diff. The files modified were changelog and libwings2.symbols (I'm not sure, but I think were these files). Regards, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
wmakerconf
Hi, wmakerconf doesn't have upstream. The official developer [1] cannot maintain the application and one person [2] started with the maintaining of the application but now is missing in action. Then, the upstream is dead. The current version of wmakerconf in debian is Orphaned. Ok, I changed the status to ITA (in adoption), but the problem is that this package don't have upstream. With the latest version of wmaker, the library Wutil includes the functions for wmakerconf, but a patch is needed, The patch is so easy, is only change the function WMWritePropListToFile, and modify the Makefile.am to include the WUtil lib (-lWutil) for the linker. sed -i -e 's/WMWritePropListToFile (\(.*\), YES))/WMWritePropListToFile(\1))/' src/*.c add -lWutil to Makefile.am The problem is... where make these changes? I can send a NMU (non maintainer upload), but this is incorrect if the upstream is dead, and probably is better to remove the package from the Debian distro. For these reasons, what should we do? Is somebody interested in this package? Is somebody using it? Is somebody interested in maintain the upstream? should we remove the package from debian? why the water wet? why the sky is blue? Cheers, kix [1] http://starplot.org/wmakerconf/ [2] https://sourceforge.net/projects/wmakerconf/ -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker 0.95.1
On 29/01/12 14:26, Paul Seelig wrote: Hello Carlos, unfrtunately, building the debian package of wmaker-0.95.1 fails with the included debian subdir because the formerly removed proplist-compat.h is still referenced. A simple diff has been attached. Thanks a lot! Paul On 01/29/2012 01:00 PM, Carlos R. Mafra wrote: I've pushed a tag 'wmaker-0.95.1' (no -crm) to the repository. The tarball can be generated by clicking the link snapshot, and it would be good if it could be uploaded to www.windowmaker.org as the latest stable release. Hi, I will send an update of the debian folder today. Best Regards, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker 0.95.1
On 29/01/12 17:31, Carlos R. Mafra wrote: On Sun, 29 Jan 2012 at 17:18:13 +0100, Rodolfo kix Garcia wrote: I hope this patch helps. Thanks Rodolfo, but it doesn't apply. [mafra@Pilar:wmaker.git]$ git am 0001-debian-New-debian-version-0.95.1-1.patch Applying: debian: New debian version 0.95.1-1 /home/mafra/git-repos/wmaker.git/.git/rebase-apply/patch:464: trailing whitespace. * wterm package suggestion removed. /home/mafra/git-repos/wmaker.git/.git/rebase-apply/patch:11504: trailing whitespace. # directories in one run /home/mafra/git-repos/wmaker.git/.git/rebase-apply/patch:11507: trailing whitespace. # /home/mafra/git-repos/wmaker.git/.git/rebase-apply/patch:11512: trailing whitespace. # /home/mafra/git-repos/wmaker.git/.git/rebase-apply/patch:11518: trailing whitespace. # error: patch failed: debian/changelog:1 error: debian/changelog: patch does not apply error: patch failed: debian/control:4 error: debian/control: patch does not apply error: patch failed: debian/copyright:7 error: debian/copyright: patch does not apply error: patch failed: debian/patches/52_libwmaker0dev.diff:1 error: debian/patches/52_libwmaker0dev.diff: patch does not apply Patch failed at 0001 debian: New debian version 0.95.1-1 When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. Here is ok :-? kix@osaka:~/tmp3$ git clone http://repo.or.cz/r/wmaker-crm.git Cloning into 'wmaker-crm'... kix@osaka:~/tmp3$ cp ../src/wmaker/wmaker-crm/debian/0001-debian-New-debian-version-0.95.1-1.patch . kix@osaka:~/tmp3$ mv 0001-debian-New-debian-version-0.95.1-1.patch wmaker-crm/ kix@osaka:~/tmp3$ cd wmaker-crm/ kix@osaka:~/tmp3/wmaker-crm$ git am 0001-debian-New-debian-version-0.95.1-1.patch Applying: debian: New debian version 0.95.1-1 /home/kix/tmp3/wmaker-crm/.git/rebase-apply/patch:464: trailing whitespace. * wterm package suggestion removed. /home/kix/tmp3/wmaker-crm/.git/rebase-apply/patch:11504: trailing whitespace. # directories in one run /home/kix/tmp3/wmaker-crm/.git/rebase-apply/patch:11507: trailing whitespace. # /home/kix/tmp3/wmaker-crm/.git/rebase-apply/patch:11512: trailing whitespace. # /home/kix/tmp3/wmaker-crm/.git/rebase-apply/patch:11518: trailing whitespace. # warning: squelched 15 whitespace errors warning: 20 lines add whitespace errors. kix@osaka:~/tmp3/wmaker-crm$ git log | more commit a82eb7790ee676d0d3b63a1240e7a28ac31f7ce8 Author: Rodolfo García Peñas (kix) k...@kix.es Date: Sun Jan 29 17:07:10 2012 +0100 debian: New debian version 0.95.1-1 This upload includes the debian changes of 0.95.0 and 0.95.1 -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker 0.95.1
On 29/01/12 17:52, Paul Seelig wrote: On 01/29/2012 05:43 PM, Rodolfo kix Garcia wrote: On 29/01/12 17:31, Carlos R. Mafra wrote: Thanks Rodolfo, but it doesn't apply. [...] Here is ok :-? When applied manually via cat ../0001-debian-New-debian-version-0.95.1-1.patch | patch -p1 from within the build tree, it cleanly applies to the sources checked out via http://repo.or.cz/w/wmaker-crm.git/snapshot/b618febb2c52a3ad3c6d77ec3559c8abebe28320.tar.gz Nonetheless, build fails at the end with following error messages: dh_install cp: cannot stat `debian/tmp/debian/debianfiles/menu/menu.prehook': No such file or directory dh_install: cp -a debian/tmp/debian/debianfiles/menu/menu.prehook debian/wmaker-common/etc/X11/WindowMaker/ returned exit code 1 make[1]: *** [override_dh_install] Error 2 See attachment for some context. These files are empty, but are included in the patch: diff --git a/debian/debianfiles/menu/menu.posthook b/debian/debianfiles/menu/menu.posthook new file mode 100644 index 000..e69de29 diff --git a/debian/debianfiles/menu/menu.prehook b/debian/debianfiles/menu/menu.prehook new file mode 100644 index 000..e69de29 -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker 0.95.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/01/12 18:46, Carlos R. Mafra wrote: On Sun, 29 Jan 2012 at 16:48:17 +, Carlos R. Mafra wrote: On Sun, 29 Jan 2012 at 17:43:16 +0100, Rodolfo kix Garcia wrote: Here is ok :-? Strange. Can you send me (offlist) your debian folder as a compressed tarball? Ok, Rodolfo sent me his folder and I applied things manually. The diff I got here was diferent from what he sent to the list, and the unique difference was on debian/changelog. I got: debian/changelog| 96 +- while his patch had debian/changelog| 106 +- I didn't investigate further why this happened, but apart from that what's on the repository now is what he sent to the list previously. The files in the git and my files are equal. All is fine :-) Thanks Carlos, kix - -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPJYw1AAoJEHsfVJByt0kjpb0QAJF0raoo2Q9ieZcLjSJ6kRku Td72xSyUnYLxaK3yLLk2FkBVr89nqmmGEsSXLp2LLM8FB/3BPfSMKx6gauonRktV FlaGxl6Vp5wpnZ9Hh2B6i+K3kkEhtoR3x2XNkcK5kk6zAG1p6RrNEknxJTsxqprp e9EvvllZoOqjQI4ECmQbPtH/tF7NQjY+pgzR5jhvK1qCHJyFahK57I1Ueg7KdSwe +QZLxpMW2QqSyWjNc2H3ql1Kk19axrJ1cmMbRrRxP6oZg3Khwlwa3oeuFwjvcoAX Qt/X3tDaqZVXfyqsPm1s6s4yYpGfKZJSYyDvyVJOApNXD4pL1f+2W6548mrGHmNB Kb3nbc9rayL79vQquar4ljZVmIHbu22t73gIjZZP3IJ3OYa9U97ZIvsfZTWIWgH5 Fv3ZRlL6OykZU3959oeOYVTXRUbK6DMOgaAUPrny6CPoW7+S6hUHqOLB462alEJc UuTF37HUGLc7/RLt9W+Blatf7faIkO7s0kGQIeMGhyoyg5JLd3E9EKEdjdfzf0y2 q+OYfI94wTWXM+DxWlYsNRqNwvudktJFwyyhUFETJ8N+LPe9F7pXVLZD/xt1h6x+ E36xNjfXHqBLQsYZd1p3plMGfiver4cdVbxuLH/WpNaEIeKX7BvcBUtBetcxlaOf Ze7a1YqrMcBpjPCbc4t2 =me36 -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 01/24] WindowMaker: Display dpy externs removed
On Fri, 27 Jan 2012 10:59:13 +, Carlos R. Mafra wrote:
On Fri, 27 Jan 2012 at 12:45:23 +0200, Rodolfo kix Garcia wrote:
On Fri, 27 Jan 2012 10:34:19 +, Carlos R. Mafra wrote:
On Fri, 27 Jan 2012 at 0:31:49 +0100, Rodolfo kix Garcia wrote:
Subject: [PATCH 01/24] WindowMaker: Display dpy externs removed
The Display variable dpy is moved to WindowMaker.h, therefore
the externs can be removed.
---
src/WindowMaker.h |2 +-
src/main.c|2 --
src/xmodifier.c |3 +--
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 9e2c5f4..47e60f8 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -444,7 +444,7 @@ typedef struct WPreferences {
/** Global Variables **/
-extern Display *dpy;
+Display*dpy;
I don't think this is right. The variable was defined in main.c
and now
you are defining it here?
Yes, is ok. The variable dpy is used in a lot of files.
WindowMaker.h is included in all of them.
Therefore, IMO, is better to remove the externs and make the
definition in one place common for all files.
Really, the variable dpy don't belongs to main.c/h, is common to
the full source code.
If you think in that, when the file is included by the preprocessor,
is somethinkg like:
/* From WindowMaker.h */
...
extern Display *dpy;
...
/* From main.c */
...
Display *.dpy;
...
Now, the code is:
/* From WindowMaker.h */
...
Display *dpy;
...
/* From main.c */
...
(nothing)
...
But a global variable can be defined only once, and now whenever
you include WindowMaker.h it will be defined in that file.
I think the patch should have only included WindowMaker.h in
xmodifier.c
and removed the extern from there.
I also must say that when I refered to removing the externs from .c
files I was thinking about external declarations of functions..
kix@macserver:~/new/wmaker-crm/src$ grep dpy * |wc
12697024 80889
kix@macserver:~/new/wmaker-crm/src$ grep dpy * | cut -d: -f1 | uniq -c
71 actions.c
33 appicon.c
10 application.c
8 appmenu.c
49 balloon.c
20 client.c
7 colormap.c
13 cycling.c
24 defaults.c
51 dialog.c
90 dock.c
6 dockedapp.c
50 event.c
98 framewin.c
2 funcs.h
52 icon.c
11 main.c
57 menu.c
29 misc.c
5 monitor.c
1 motif.c
96 moveres.c
5 pixmap.c
11 properties.c
3 resources.c
8 rootmenu.c
70 screen.c
5 session.c
6 shutdown.c
10 stacking.c
57 startup.c
23 superfluous.c
11 switchpanel.c
32 texture.c
1 texture.h
5 usermenu.c
8 wcore.c
100 window.c
1 WindowMaker.h
3 winmenu.c
12 winspector.c
38 wmspec.c
37 workspace.c
28 xdnd.c
5 xinerama.c
2 xmodifier.c
2 xutil.c
3 xutil.h
kix@macserver:~/new/wmaker-crm/src$
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 01/24] WindowMaker: Display dpy externs removed
On Fri, 27 Jan 2012 10:59:13 +, Carlos R. Mafra wrote:
On Fri, 27 Jan 2012 at 12:45:23 +0200, Rodolfo kix Garcia wrote:
On Fri, 27 Jan 2012 10:34:19 +, Carlos R. Mafra wrote:
On Fri, 27 Jan 2012 at 0:31:49 +0100, Rodolfo kix Garcia wrote:
Subject: [PATCH 01/24] WindowMaker: Display dpy externs removed
The Display variable dpy is moved to WindowMaker.h, therefore
the externs can be removed.
---
src/WindowMaker.h |2 +-
src/main.c|2 --
src/xmodifier.c |3 +--
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 9e2c5f4..47e60f8 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -444,7 +444,7 @@ typedef struct WPreferences {
/** Global Variables **/
-extern Display *dpy;
+Display*dpy;
I don't think this is right. The variable was defined in main.c
and now
you are defining it here?
Yes, is ok. The variable dpy is used in a lot of files.
WindowMaker.h is included in all of them.
Therefore, IMO, is better to remove the externs and make the
definition in one place common for all files.
Really, the variable dpy don't belongs to main.c/h, is common to
the full source code.
If you think in that, when the file is included by the preprocessor,
is somethinkg like:
/* From WindowMaker.h */
...
extern Display *dpy;
...
/* From main.c */
...
Display *.dpy;
...
Now, the code is:
/* From WindowMaker.h */
...
Display *dpy;
...
/* From main.c */
...
(nothing)
...
I am not sure about nothing now. Perhaps is not ok. :-?
But a global variable can be defined only once, and now whenever
you include WindowMaker.h it will be defined in that file.
I think the patch should have only included WindowMaker.h in
xmodifier.c
and removed the extern from there.
I also must say that when I refered to removing the externs from .c
files I was thinking about external declarations of functions..
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 01/24] WindowMaker: Display dpy externs removed
On Fri, 27 Jan 2012 12:04:06 +, Carlos R. Mafra wrote: On Fri, 27 Jan 2012 at 12:52:06 +0100, BALATON Zoltan wrote: But a global variable can be defined only once, and now whenever you include WindowMaker.h it will be defined in that file. I also think the original version is cleaner, because the variable is defined only once and then declared for use as extern in the header. This ensures that all files use the same variable. If the definition is in the header then the variable is always defined even if the resulting code is not linked to main.o. This is probably not what's intended. Exactly. I'll skip this patch. My time to review is short right now, I'll take a look at the rest during the weekend if all goes well. If more people have comments, that will great. Ok, probably most of the patches should be skiped. Only a few remove unused variables. Check the 24/24, because is about defines. No problem. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 01/24] WindowMaker: Display dpy externs removed
On Fri, 27 Jan 2012 12:02:45 -0200, Haroldo Gambini Santos wrote: Hi Rodolfo, If I understand your proposal, there might be a problem: If you define a variable in a C header which is included in two source files then these files when compiled will reserve space for this variable in *two different* memory locations, isn't ??? Yes yes, I didn't what I was thinking. Some (most) patches are wrong. On 27-01-2012 10:04, Carlos R. Mafra wrote: On Fri, 27 Jan 2012 at 12:52:06 +0100, BALATON Zoltan wrote: But a global variable can be defined only once, and now whenever you include WindowMaker.h it will be defined in that file. I also think the original version is cleaner, because the variable is defined only once and then declared for use as extern in the header. This ensures that all files use the same variable. If the definition is in the header then the variable is always defined even if the resulting code is not linked to main.o. This is probably not what's intended. Exactly. I'll skip this patch. My time to review is short right now, I'll take a look at the rest during the weekend if all goes well. If more people have comments, that will great. -- = Haroldo Gambini Santos Computing Department - Universidade Federal de Ouro Preto - UFOP email: haroldo [at ] iceb.ufop.br home/research page: www.decom.ufop.br/haroldo/ -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 1/3] WindowMaker: Remove not needed ProgName extend
From 53bf8d480c8109f4c4a79c1c9ce4e0dd728a6467 Mon Sep 17 00:00:00 2001
From: Rodolfo García Peñas (kix) k...@kix.es
Date: Wed, 25 Jan 2012 09:04:41 +0100
Subject: [PATCH 1/3] WindowMaker: Remove not needed ProgName extend
The extend ProgName in WindowMaker.h is not needed because this variable is
only in main.c
---
src/WindowMaker.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 9e2c5f4..5168910 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -445,7 +445,6 @@ typedef struct WPreferences {
/** Global Variables **/
extern Display *dpy;
-extern char *ProgName;
extern unsigned int ValidModMask;
extern char WProgramState;
extern char WProgramSigState;
--
1.7.2.3
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 2/3] WindowMaker: removed WMPropList because are not used
From 07ff859873cde159b9c4134810c776549304e3d4 Mon Sep 17 00:00:00 2001
From: Rodolfo García Peñas (kix) k...@kix.es
Date: Wed, 25 Jan 2012 09:15:44 +0100
Subject: [PATCH 2/3] WindowMaker: removed WMPropList because are not used
The variables WMPropList are not used, then can be removed.
---
src/main.c |3 ---
src/wdefaults.c |5 -
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/src/main.c b/src/main.c
index c17dcef..9fc9976 100644
--- a/src/main.c
+++ b/src/main.c
@@ -79,9 +79,6 @@ int wScreenCount = 0;
WPreferences wPreferences;
-WMPropList *wDomainName;
-WMPropList *wAttributeDomainName;
-
WShortKey wKeyBindings[WKBD_LAST];
/* defaults domains */
diff --git a/src/wdefaults.c b/src/wdefaults.c
index eba2573..8df9dc8 100644
--- a/src/wdefaults.c
+++ b/src/wdefaults.c
@@ -44,7 +44,6 @@
/* Global stuff */
extern WPreferences wPreferences;
-extern WMPropList *wAttributeDomainName;
extern WDDomain *WDWindowAttributes;
/* Local stuff */
@@ -124,10 +123,6 @@ static void init_wdefaults(WScreen * scr)
AnyWindow = WMCreatePLString(*);
No = WMCreatePLString(No);
- /*
- if (!scr-wattribs) {
- scr-wattribs = PLGetDomain(wAttributeDomainName);
- } */
}
static WMPropList *get_value(WMPropList * dict_win, WMPropList * dict_class,
WMPropList * dict_name,
--
1.7.2.3
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 3/3] WindowMaker: ProcessPendingEvents moved to event.h
From 81780e33662b533d335a16b695d147979b24f9c9 Mon Sep 17 00:00:00 2001 From: Rodolfo García Peñas (kix) k...@kix.es Date: Wed, 25 Jan 2012 09:26:19 +0100 Subject: [PATCH 3/3] WindowMaker: ProcessPendingEvents moved to event.h The function ProcessPendingEvents is moved to the new file event.h. Now the func tion don't need to be extern. --- src/Makefile.am |1 + src/event.c |1 + src/workspace.c |2 +- 3 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 0521d11..8946a6d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -32,6 +32,7 @@ wmaker_SOURCES = \ dockedapp.c \ dock.h \ event.c \ + event.h \ extend_pixmaps.h \ framewin.c \ framewin.h \ diff --git a/src/event.c b/src/event.c index 1a7b4cb..f2adc14 100644 --- a/src/event.c +++ b/src/event.c @@ -66,6 +66,7 @@ #include balloon.h #include xinerama.h #include wmspec.h +#include event.h / Global Variables **/ extern XContext wWinContext; diff --git a/src/workspace.c b/src/workspace.c index dc53d03..b519bbc 100644 --- a/src/workspace.c +++ b/src/workspace.c @@ -48,6 +48,7 @@ #include appicon.h #include wmspec.h #include xinerama.h +#include event.h #define MAX_SHORTCUT_LENGTH 32 #define WORKSPACE_NAME_DISPLAY_PADDING 32 @@ -55,7 +56,6 @@ extern int ignore_wks_change; extern WPreferences wPreferences; extern XContext wVEdgeContext; -extern void ProcessPendingEvents(); static WMPropList *dWorkspaces = NULL; static WMPropList *dClip, *dName; diff --git a/src/event.h b/src/event.h new file mode 100644 index 000..8b82223 --- /dev/null +++ b/src/event.h @@ -0,0 +1 @@ +void ProcessPendingEvents(void); -- 1.7.2.3 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Patches
Forget the yesterday patches. I sent three patches now including the good patches of yesterday. If somebody can make the patch of the defines (patch no 24)... -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Fwd: wmaker 0.95.0+20111028-4 MIGRATED to testing
On Thu, 26 Jan 2012 10:04:09 +0100, Andreas Tscharner wrote: On 24.01.2012 17:46, Rodolfo kix Garcia wrote: Hi, [snip] Fyi, wterm and fsviewer are now removed from debian unstable. So I noticed. As I use fsviewer quite regularly, I didn't like it... IIRC the problem was that fsviewer depends on libwraster and libwraster is no longer used by WindowMaker so it was abandoned? What about packaging fsviewer with libwraster? Hi Andreas, the problem was that the upstream developer of fsviewer (and wterm) don't replied the mails. Is missing in action, and for this reason the package cannot be updated. This was a problem because fsviewer requires libwmaker0-dev, and without libwmaker0-dev the wmaker package cannot be in testing. My idea wasn't remove the packages, but I didn't have other option. I talked about this with two Debian Developers, and they say the same; contact with the upstream, if he don't reply think if you want to be the new upstream, else, create a package remove request. There are two different options now: 1. Include the libwmaker0-dev package in the upstream of fsviewer. Then the package libwmaker0-dev is provided by fsviewer source package. 2. Remove the libwmaker0-dev functions of fsviewer (rewrite fsviewer), therefore the package fsviewer won't need libwmaker0-dev In both cases, probably you will be the new upstream. I didn't have more time for these packages (and I don't use them). Best Regards, kix Best regards Andreas -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 01/24] WindowMaker: Display dpy externs removed
From b99540302d4c8be6cd39629a2ac0938a471eaaac Mon Sep 17 00:00:00 2001
From: Rodolfo García Peñas (kix) k...@kix.es
Date: Wed, 25 Jan 2012 02:21:18 +0100
Subject: [PATCH 01/24] WindowMaker: Display dpy externs removed
The Display variable dpy is moved to WindowMaker.h, therefore the externs can
be removed.
---
src/WindowMaker.h |2 +-
src/main.c|2 --
src/xmodifier.c |3 +--
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 9e2c5f4..47e60f8 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -444,7 +444,7 @@ typedef struct WPreferences {
/** Global Variables **/
-extern Display *dpy;
+Display*dpy;
extern char *ProgName;
extern unsigned int ValidModMask;
extern char WProgramState;
diff --git a/src/main.c b/src/main.c
index c17dcef..bc68fb7 100644
--- a/src/main.c
+++ b/src/main.c
@@ -62,8 +62,6 @@
/* general info */
-Display *dpy;
-
char *ProgName;
unsigned int ValidModMask = 0xff;
diff --git a/src/xmodifier.c b/src/xmodifier.c
index 7bae013..fad72eb 100644
--- a/src/xmodifier.c
+++ b/src/xmodifier.c
@@ -36,8 +36,7 @@ Perpetrator: Sudish Joseph s...@eng.mindspring.net, Sept.
1997. */
#include WINGs/WUtil.h
#include xmodifier.h
-
-extern Display *dpy;
+#include WindowMaker.h
//
/*keymap handling */
--
1.7.2.3
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
From b99540302d4c8be6cd39629a2ac0938a471eaaac Mon Sep 17 00:00:00 2001
From: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Wed, 25 Jan 2012 02:21:18 +0100
Subject: [PATCH 01/24] WindowMaker: Display dpy externs removed
The Display variable dpy is moved to WindowMaker.h, therefore the externs can be removed.
---
src/WindowMaker.h |2 +-
src/main.c|2 --
src/xmodifier.c |3 +--
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 9e2c5f4..47e60f8 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -444,7 +444,7 @@ typedef struct WPreferences {
/** Global Variables **/
-extern Display *dpy;
+Display *dpy;
extern char *ProgName;
extern unsigned int ValidModMask;
extern char WProgramState;
diff --git a/src/main.c b/src/main.c
index c17dcef..bc68fb7 100644
--- a/src/main.c
+++ b/src/main.c
@@ -62,8 +62,6 @@
/* general info */
-Display *dpy;
-
char *ProgName;
unsigned int ValidModMask = 0xff;
diff --git a/src/xmodifier.c b/src/xmodifier.c
index 7bae013..fad72eb 100644
--- a/src/xmodifier.c
+++ b/src/xmodifier.c
@@ -36,8 +36,7 @@ Perpetrator: Sudish Joseph s...@eng.mindspring.net, Sept. 1997. */
#include WINGs/WUtil.h
#include xmodifier.h
-
-extern Display *dpy;
+#include WindowMaker.h
//
/*keymap handling */
--
1.7.2.3
