Build questions
Hi, I am creating the wmaker package for Debian. I have some questions: 1. The build process fails because th script Makefile.am calls configure-documentation, but the --ignore-prg 'runstatedir' is not included. 2. The build scripts modififies the INSTALL-WMAKER and the README.i18n files. The modification is "Published by The Window Maker team on ", but the date is the compilation date. IMO, this is not right. The Published date must be fixed. In the Debian build process, the original source file and the build source should be the same. In this case, the build process fails if we run it twice. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 2/2] Enable usermenu
Hi, I think this patch should be removed. The menu is created and painted when the application starts but is not removed when the application is closed. Without the patch, the menu is created and painted when te application get the focus (with mouse), and removed when the application lost the focus, for example, when is closed. We should write a patch to solve the problem of getting the focus using keyboard (alt+tab). Cheers, kix "Rodolfo García Peñas (kix)" <k...@kix.es> escribió: This patch is mostly for testing. "Rodolfo García Peñas (kix)" <k...@kix.es> escribió: This patch enables the usermenu when the application is launched and the usermenu file exists. Signed-off-by: Rodolfo García Peñas (kix) <k...@kix.es> --- src/actions.c | 1 + src/application.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/src/actions.c b/src/actions.c index 5adfab4..b210888 100644 --- a/src/actions.c +++ b/src/actions.c @@ -225,6 +225,7 @@ void wSetFocusTo(WScreen *scr, WWindow *wwin) wUserMenuRefreshInstances(napp->menu, wwin); #endif /* USER_MENU */ + /* kix: Only menu map with mouse, not alt+tab! */ if (wwin->flags.mapped) wAppMenuMap(napp->menu, wwin); } diff --git a/src/application.c b/src/application.c index c43df04..6ff3d3f 100644 --- a/src/application.c +++ b/src/application.c @@ -129,6 +129,8 @@ WApplication *wApplicationCreate(WWindow * wwin) #ifdef USER_MENU if (!wapp->menu) wapp->menu = wUserMenuGet(scr, wapp->main_window_desc); + + wAppMenuMap(wapp->menu, wwin); #endif /* Set application wide attributes from the leader */ -- 2.5.0 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Josip Deanovic djosip+n...@linuxpages.net escribió: Josip DeanovicOn Monday 2015-08-24 21:53:25 wrote: BTW, Wouldn't it be a better to use the path ~/GNUstep/Library/WindowMaker/UserMenus than ~/GNUstep/Defaults/UserMenus I have googled for UserMenus and gnustep and found that number of people found that this feature works if they use the path ~/GNUstep/Library/WindowMaker/UserMenus So, unless there is a good reason to put that directory under the ~/GNUstep/Defaults maybe it would be a good idea to just fix the documentation and leave the path as it was. That also gives the answer to the original question in the thread: yes, we can expect that there are people who learned to use that feature. :-) Looking trough the NEWS file... The feature first appeared in 0.53.0 And later, in version 0.60.0 it says: -BEGIN- User Menu - The user menu is now a compile time option disabled by default. Supply --enable-usermenu to configure to enable it. -END- and... -BEGIN- Application User Menu Path Changes -- Default configuration for user specific menus installed in /usr/local/share/WindowMaker/UserMenus or $(datadir)/WindowMaker/UserMenus and ~/GNUstep/Library/WindowMaker/UserMenus. -END- So actually regarding the path everything was fine in the code, we just didn't find it in the documentation right away. I would suggest an addition of a line under the initial announcement with the note that path has changed to ~/GNUstep/Library/WindowMaker/UserMenus in a later versions so that people don't get confused. I updated the patch. Thanks for your comments. kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 2/2] Enable usermenu
This patch is mostly for testing. Rodolfo García Peñas (kix) k...@kix.es escribió: This patch enables the usermenu when the application is launched and the usermenu file exists. Signed-off-by: Rodolfo García Peñas (kix) k...@kix.es --- src/actions.c | 1 + src/application.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/src/actions.c b/src/actions.c index 5adfab4..b210888 100644 --- a/src/actions.c +++ b/src/actions.c @@ -225,6 +225,7 @@ void wSetFocusTo(WScreen *scr, WWindow *wwin) wUserMenuRefreshInstances(napp-menu, wwin); #endif /* USER_MENU */ + /* kix: Only menu map with mouse, not alt+tab! */ if (wwin-flags.mapped) wAppMenuMap(napp-menu, wwin); } diff --git a/src/application.c b/src/application.c index c43df04..6ff3d3f 100644 --- a/src/application.c +++ b/src/application.c @@ -129,6 +129,8 @@ WApplication *wApplicationCreate(WWindow * wwin) #ifdef USER_MENU if (!wapp-menu) wapp-menu = wUserMenuGet(scr, wapp-main_window_desc); + + wAppMenuMap(wapp-menu, wwin); #endif /* Set application wide attributes from the leader */ -- 2.5.0 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/2] usermenu.c Avoid compiler warnings
Hi Carlos,
you can apply this patch to the git without problems.
Cheers,
kix
Rodolfo García Peñas (kix) k...@kix.es escribió:
This patch includes some changes to avoid compiler warnings and
some code style.
Compiler warnings are:
- notifyClient, do not uses the menu argument. Including (void) menu.
- WUserMenuData, keyover: label is not used.
- configureUserMenu, params is not initialized.
- configureUserMenu, mentry is not initialized.
Signed-off-by: Rodolfo García Peñas (kix) k...@kix.es
---
src/usermenu.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/src/usermenu.c b/src/usermenu.c
index c349810..b5c0cfe 100644
--- a/src/usermenu.c
+++ b/src/usermenu.c
@@ -87,7 +87,7 @@ typedef struct {
int key_no;
} WUserMenuData;
-static void notifyClient(WMenu * menu, WMenuEntry * entry)
+static void notifyClient(WMenu *menu, WMenuEntry *entry)
{
XEvent event;
WUserMenuData *data = entry-clientdata;
@@ -95,6 +95,8 @@ static void notifyClient(WMenu * menu, WMenuEntry * entry)
Window window;
int i;
+ (void) menu;
+
window = scr-focused_window-client_win;
for (i = 0; i data-key_no; i++) {
@@ -128,20 +130,19 @@ static void removeUserMenudata(void *menudata)
wfree(data);
}
-static WUserMenuData *convertShortcuts(WScreen * scr, WMPropList * shortcut)
+static WUserMenuData *convertShortcuts(WScreen *scr, WMPropList *shortcut)
{
WUserMenuData *data;
KeySym ksym;
char *k, buf[MAX_SHORTCUT_LENGTH], *b;
int keycount, i, j, mod;
- if (WMIsPLString(shortcut)) {
+ if (WMIsPLString(shortcut))
keycount = 1;
- } else if (WMIsPLArray(shortcut)) {
+ else if (WMIsPLArray(shortcut))
keycount = WMGetPropListItemCount(shortcut);
- } else {
+ else
return NULL;
- }
data = wmalloc(sizeof(WUserMenuData));
if (!data)
@@ -160,7 +161,7 @@ static WUserMenuData *convertShortcuts(WScreen *
scr, WMPropList * shortcut)
else
wstrlcpy(buf, WMGetFromPLString(shortcut),
MAX_SHORTCUT_LENGTH);
- b = (char *)buf;
+ b = (char *) buf;
while ((k = strchr(b, '+')) != NULL) {
*k = 0;
@@ -181,8 +182,6 @@ static WUserMenuData *convertShortcuts(WScreen *
scr, WMPropList * shortcut)
j++;
}
- keyover:
-
/* get key */
if (!j) {
puts(fatal j);
@@ -190,17 +189,18 @@ static WUserMenuData *convertShortcuts(WScreen
* scr, WMPropList * shortcut)
wfree(data);
return NULL;
}
+
data-key_no = j;
data-screen = scr;
return data;
}
-static WMenu *configureUserMenu(WScreen * scr, WMPropList * plum)
+static WMenu *configureUserMenu(WScreen *scr, WMPropList *plum)
{
char *mtitle;
WMenu *menu = NULL;
- WMPropList *elem, *title, *command, *params;
+ WMPropList *elem, *title, *command, *params = NULL;
int count, i;
WUserMenuData *data;
@@ -219,18 +219,18 @@ static WMenu *configureUserMenu(WScreen * scr,
WMPropList * plum)
return NULL;
mtitle = WMGetFromPLString(elem);
-
menu = wMenuCreateForApp(scr, mtitle, True);
for (i = 1; i count; i++) {
elem = WMGetFromPLArray(plum, i);
if (WMIsPLArray(WMGetFromPLArray(elem, 1))) {
WMenu *submenu;
- WMenuEntry *mentry;
+ WMenuEntry *mentry = NULL;
submenu = configureUserMenu(scr, elem);
if (submenu)
mentry = wMenuAddCallback(menu,
submenu-frame-title, NULL, NULL);
+
wMenuEntrySetCascade(menu, mentry, submenu);
} else {
int idx = 0;
@@ -277,7 +277,7 @@ static WMenu *configureUserMenu(WScreen * scr,
WMPropList * plum)
return menu;
}
-void wUserMenuRefreshInstances(WMenu * menu, WWindow * wwin)
+void wUserMenuRefreshInstances(WMenu *menu, WWindow *wwin)
{
int i, j, count, paintflag;
@@ -301,10 +301,12 @@ void wUserMenuRefreshInstances(WMenu * menu,
WWindow * wwin)
break;
}
}
+
if (oldflag != menu-entries[i]-flags.enabled)
paintflag = 1;
}
}
+
for (i = 0; i menu-cascade_no; i++) {
if (!menu-cascades[i]-flags.brother)
wUserMenuRefreshInstances(menu-cascades[i], wwin);
@@ -326,14 +328,15 @@ static WMenu *readUserMenuFile(WScreen *scr,
const char *file_name)
menu = configureUserMenu(scr, plum
Re: Question about menus (usermenu, appmenu)
Josip Deanovic djosip+n...@linuxpages.net escribió: On Monday 2015-08-24 05:48:08 Rodolfo García Peñas wrote: IMO we could remove these menus because: 1. Are not documented. The user don't know how to create/use the menu. 2. Are not examples, only in the source code we can find how to configure the menu. 3. The line to show the menu (in the source) is difficult to reach by the user. I am using the --enable-usermenu option every time when I prepare windowmaker for compilation but I don't think that I have ever managed to get some time and actually test and use the feature. The feature seem to appear in the 0.53.0 and it is documented in the NEWS file: -BEGIN- Application User Menu - Applications with an appicon can have a user defined menu. This menu will emulate keyboard events, and will be sent to the applications' window(s), thus the application must accept key combinations (CTRL+N for instance). To enable this feature, #define USER_MENU in src/wconfig.h and place menu files in ~/GNUstep/Defaults/UserMenus (/usr/local/etc/WindowMaker/UserMenus globally). The user menu is in PropList format and the filename is in: instance name.class name.menu or application's main window. (Example: the menu for xcalc would be - xcalc.XCalc.menu) Example user menu syntax: ( Calculator, (Put 1, SHORTCUT, 2), (Functions, (Put 2, SHORTCUT, 2), (Put 3,4 and 5, SHORTCUT, (3,4,5)) ), (Exit, SHORTCUT, Control+q) ) -END- If I understand correctly this feature would make possible to use the user defined menu or keyboard shortcut on the appicon of an application to start emulating keyboard events on the application window. Hello, I tried to create the menu file (~/GNUstep/Defaults/UserMenus/xcalc.XCalc.menu) with the contents included in the NEWS file. I am unable to use the menu. IMO the call is wrong, because is set in the wSetFocusTo function and in a place probably unreacheable. Could someone try to show the menu? I will think about it, perhalps is a good idea have this menu... OTOH, the usermenu is not compiled in Debian/Ubuntu by default. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Quoting Josip Deanovic djosip+n...@linuxpages.net: On Monday 2015-08-24 14:07:48 Rodolfo García Peñas wrote: Josip Deanovic djosip+n...@linuxpages.net escribió: I am using the --enable-usermenu option every time when I prepare windowmaker for compilation but I don't think that I have ever managed to get some time and actually test and use the feature. The feature seem to appear in the 0.53.0 and it is documented in the NEWS file: -BEGIN- Application User Menu - Applications with an appicon can have a user defined menu. This menu will emulate keyboard events, and will be sent to the applications' window(s), thus the application must accept key combinations (CTRL+N for instance). To enable this feature, #define USER_MENU in src/wconfig.h and place menu files in ~/GNUstep/Defaults/UserMenus (/usr/local/etc/WindowMaker/UserMenus globally). The user menu is in PropList format and the filename is in: instance name.class name.menu or application's main window. (Example: the menu for xcalc would be - xcalc.XCalc.menu) Example user menu syntax: ( Calculator, (Put 1, SHORTCUT, 2), (Functions, (Put 2, SHORTCUT, 2), (Put 3,4 and 5, SHORTCUT, (3,4,5)) ), (Exit, SHORTCUT, Control+q) ) -END- If I understand correctly this feature would make possible to use the user defined menu or keyboard shortcut on the appicon of an application to start emulating keyboard events on the application window. Hello, I tried to create the menu file (~/GNUstep/Defaults/UserMenus/xcalc.XCalc.menu) with the contents included in the NEWS file. I am unable to use the menu. IMO the call is wrong, because is set in the wSetFocusTo function and in a place probably unreacheable. Could someone try to show the menu? I will think about it, perhalps is a good idea have this menu... OTOH, the usermenu is not compiled in Debian/Ubuntu by default. I have tried to configure it for xlogo.XLogo.menu and I don't see any menu (unfortunately). Maybe there is some keyboard shortcut which need to be used to activate it? Or maybe some other way to activate it? Hi, I found one problem, the path was wrong in the code (or in the doc, IMO, in the code). Then, I added the menu map when the window is created. Probably could be a good idea create a menu entry to show/hide the menu. Ok, now we can test it. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip Deanovic djosip+n...@linuxpages.net escribió: Josip DeanovicOn Sunday 2015-08-23 19:25:32 wrote: On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: Josip, the patch should fix the issue and it's in the #next branch already. Would you mind testing it? I'll test it in the next 30 minutes. Ok, I have tested it and I can confirm that feature now works but while testing it I have encountered undesirable issues such as windowmaker crash and restart. So this is the procedure I used while testing: 1. I am using kwrite application for my tests 2. Start kwrite application on the command line 3. Checking Application Specific window attributes - No application icon - unselected - Shared application icon - selected 4. Drag the application icon to the dock 5. Enable (select) the option No application icon for the application 6. Close the application and run multiple instances of the application using double-click on the docked icon - everything works fine 7. In the application Specific menu disable (unselect) the option No application icon - windowmaker crashes and restarts -- Josip Deanovic Hi Josip, confirmed, I am working on it. Thanks Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic djosip+n...@linuxpages.net: On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: Solved. Thanks for your report. Thank you for the effort. I have just tested the code from the fresh next branch and the issue still exist (Windowmaker crashes and restarts). Using the same steps? Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip Deanovic djosip+n...@linuxpages.net escribió: On Sunday 2015-08-23 18:32:06 Rodolfo García Peñas wrote: Hi Josip, confirmed, I am working on it. Thanks Cool. Thank you. Solved. Thanks for your report. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic djosip+n...@linuxpages.net: On Sunday 2015-08-23 20:02:58 Rodolfo García Peñas wrote: Quoting Josip Deanovic djosip+n...@linuxpages.net: On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: Solved. Thanks for your report. Thank you for the effort. I have just tested the code from the fresh next branch and the issue still exist (Windowmaker crashes and restarts). Using the same steps? Yes. I have even relog (not just restart) to make sure that wmaker has been completely restarted. Thanks, I will continue with this problem tomorrow. I think I know the problem, but I need do a deep analysis. Regards, kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Hi Carlos, yes. I just sent the patch. Window Maker sometimes checks the flags, sometimes only the pointers. Cheers, kix Carlos R. Mafra crma...@gmail.com escribió: Rodolfo? Any ideas here? On Sat, 22 Aug 2015 at 18:04:27 +0200, Josip Deanovic wrote: On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: On Sat, 22 Aug 2015 at 15:11:33 +0200, Josip Deanovic wrote: Let's not remove anything until we find out what this really is. There are some features still missing because of such actions in the past. Which feature was removed that you are missing? The one I am talking for over a year now. :-) In previous versions e.g. 0.80.2 up until 0.95.3 when an application attributes are set with NoAppIcon = Yes; (No application icon option in attributes window), it was possible to launch multiple instances of the application from wmdock using double-click. After doing a git bisect per your suggestion I have found and reported this: bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit commit bc0700e016c67791d3e3eab855543d849f4ce786 Author: Rodolfo GarcÃa Peñas (kix) k...@kix.es Date: Mon Jun 18 11:15:19 2012 +0200 Create WAppIcon always When the application is created, the WAppIcon now is created always, but it is only painted if the flag is not set. The icon initialization to NULL can be done now at app_icon_create_from_docks because it is always called. :04 04 7c58877ad5af211acaddac5288848c2ade7b04cb 33d52affb385d22fbf04ebad3c628b714008785d M src For the complete thread look for a subject Double-click on application in wmdock does not launch the application if one instance is already running. -- Josip Deanovic -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Hi Josip,
thanks for your report. Sorry about that. Patch is attached.
Perhaps we should use a different flag to run the application more
times from the same dock icon.
Cheers,
kix
Josip Deanovic djosip+n...@linuxpages.net escribió:
On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote:
On Sat, 22 Aug 2015 at 15:11:33 +0200, Josip Deanovic wrote:
Let's not remove anything until we find out what this really is.
There are some features still missing because of such actions in
the past.
Which feature was removed that you are missing?
The one I am talking for over a year now. :-)
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with NoAppIcon = Yes; (No application icon option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
For the complete thread look for a subject Double-click on application in
wmdock does not launch the application if one instance is already
running.
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
From ccff70a14d18fb68b2869f1fe05d6069c9552b26 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20=28kix=29?=
k...@kix.es
Date: Sun, 23 Aug 2015 17:33:38 +0200
Subject: [PATCH] create_appicon_from_dock checks if no_appicon flag is set
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
As Josip Deanovic reported:
---8---
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with NoAppIcon = Yes; (No application icon option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix) k...@kix.es
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
---8---
This patch reverts this change (not the patch). Now the function
create_appicon_from_dock checks if the flag no_appicon is set,
and then, do not execute the code related to the appicon.
Signed-off-by: Rodolfo García Peñas (kix) k...@kix.es
---
src/appicon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/appicon.c b/src/appicon.c
index 302066d..08331c7 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -1180,7 +1180,7 @@ static void create_appicon_from_dock(WWindow *wwin, WApplication *wapp, Window m
}
/* If created, then set some flags */
- if (wapp-app_icon) {
+ if (wapp-app_icon !WFLAGP(wapp-main_window_desc, no_appicon)) {
WWindow *mainw = wapp-main_window_desc;
wapp-app_icon-running = 1;
--
2.5.0
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic djosip+n...@linuxpages.net: On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: It is there now. I have compiled a newest version and tested every combination I could think of and works fine. No crash any more, feature works as expected. I would say that we can close this case. Thanks Josip, Regards, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Quoting BALATON Zoltan bala...@eik.bme.hu: On Sat, 22 Aug 2015, Josip Deanovic wrote: On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: Which feature was removed that you are missing? The one I am talking for over a year now. :-) Also app icon caching was broken around the same time. The app icon cache in CachedPixmaps was meant to store icons retrieved from X clients so the dock or clip can display those when the client is not running like after startup. The cache should contain only such icons and the path should never appear in WMWindowAttributes because the cache is an internal thing used to look up icons not otherwise available. If you look at your WMWindowAttributes now it is full of entries referring to the cache that should not be there and if you look at the cache dir you'll find a lot of icons from all apps you've ever started while there should be only the few docked ones that use client side icons. Also the cache is never cleaned up only new icons are added to it. Hello, Yesterday I sent some patches to solve these problems. Could you try them? The icon handling code was a bit complicated before but worked (maybe cache cleanup was broken before) until overzealous simplification attempts have messed it up so much that it is now difficult to untangle. Even more so because the object oriented design was also messed up by renaming and moving methods around so now it is not clear what object methods these functions were meant to be. I think the principles to follow should be: 1. K.I.S.S. 2. If ain't broke don't fix it. 3. If you don't understand it don't touch it. (That is, think about all possible implications of your proposed change because it may work with your particular settings but a lot of things can be set by preferences.) I agree with you. But some things in windowmaker are not clear. Some code is old and/or unused. Most of my patches are related to K.I.S.S. and remove unused code. Removing usermenu and appmenu is because IMO, these menus are not used, but I am not sure (Is easy to find if one person is using it, but very difficult to kwow if nobody is using these menus). IMO we could remove these menus because: 1. Are not documented. The user don't know how to create/use the menu. 2. Are not examples, only in the source code we can find how to configure the menu. 3. The line to show the menu (in the source) is difficult to reach by the user. Cheers, kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Hi,
if nobody is using these menus and nobody knows about them, my
proposal is remove this code. I will do it. Vote?
Cheers,
kix
Quoting Rodolfo García Peñas (kix) k...@kix.es:
Hello,
I am reading a lot of code and I am not sure about the usage of
usermenu and appmenu in wmaker.
Do you have more info about these menus? How can use/call them? Both
uses the wApplication-menu pointer. The variable wapp-menu is only
used in actions.c as wAppMenuMap(napp-menu, wwin), but I don't know
how to show this menu:
223 if (napp !wasfocused) {
224 #ifdef USER_MENU
225 wUserMenuRefreshInstances(napp-menu, wwin);
226 #endif /* USER_MENU */
227
228 if (wwin-flags.mapped)
229 wAppMenuMap(napp-menu, wwin);
230 }
There is no info in the wmaker manual.
Are these menus really used? We need this code? Could we remove it?
Cheers,
kix
PS. Code about this menus:
appmenu:
appmenu.h
25 WMenu *wAppMenuGet(WScreen *scr, Window window);
26 void wAppMenuDestroy(WMenu *menu);
27
28 void wAppMenuMap(WMenu *menu, WWindow *wwin);
29 void wAppMenuUnmap(WMenu *menu);
client.c:
600 if (wapp) {
601 wapp-menu = *wAppMenuGet*(scr, wwin-main_window);
602 }
603 if (wPreferences.auto_arrange_icons) {
604 wArrangeIcons(wwin-screen_ptr, True);
605 }
606 } else {
607 wapp-menu = *wAppMenuGet*(wwin-screen_ptr, wwin-main_window);
application.c
127
128 wapp-menu = *wAppMenuGet*(scr, main_window);
129 #ifdef USER_MENU
130 if (!wapp-menu)
131 wapp-menu = wUserMenuGet(scr, wapp-main_window_desc);
132 #endif
133
Usermenu:
usermenu.h has these functions:
28 WMenu *wUserMenuGet(WScreen *scr, WWindow *wwin);
29 void wUserMenuRefreshInstances(WMenu *menu, WWindow *wwin);
The function wUserMenuGet is used only in application.c, overriding
the previous call for appmenu (se above).
129 #ifdef USER_MENU
130 if (!wapp-menu)
131 wapp-menu = wUserMenuGet(scr, wapp-main_window_desc);
132 #endif
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Question about menus (usermenu, appmenu)
Hello,
I am reading a lot of code and I am not sure about the usage of
usermenu and appmenu in wmaker.
Do you have more info about these menus? How can use/call them? Both
uses the wApplication-menu pointer. The variable wapp-menu is only
used in actions.c as wAppMenuMap(napp-menu, wwin), but I don't know
how to show this menu:
223 if (napp !wasfocused) {
224 #ifdef USER_MENU
225 wUserMenuRefreshInstances(napp-menu, wwin);
226 #endif /* USER_MENU */
227
228 if (wwin-flags.mapped)
229 wAppMenuMap(napp-menu, wwin);
230 }
There is no info in the wmaker manual.
Are these menus really used? We need this code? Could we remove it?
Cheers,
kix
PS. Code about this menus:
appmenu:
appmenu.h
25 WMenu *wAppMenuGet(WScreen *scr, Window window);
26 void wAppMenuDestroy(WMenu *menu);
27
28 void wAppMenuMap(WMenu *menu, WWindow *wwin);
29 void wAppMenuUnmap(WMenu *menu);
client.c:
600 if (wapp) {
601 wapp-menu = *wAppMenuGet*(scr, wwin-main_window);
602 }
603 if (wPreferences.auto_arrange_icons) {
604 wArrangeIcons(wwin-screen_ptr, True);
605 }
606 } else {
607 wapp-menu = *wAppMenuGet*(wwin-screen_ptr, wwin-main_window);
application.c
127
128 wapp-menu = *wAppMenuGet*(scr, main_window);
129 #ifdef USER_MENU
130 if (!wapp-menu)
131 wapp-menu = wUserMenuGet(scr, wapp-main_window_desc);
132 #endif
133
Usermenu:
usermenu.h has these functions:
28 WMenu *wUserMenuGet(WScreen *scr, WWindow *wwin);
29 void wUserMenuRefreshInstances(WMenu *menu, WWindow *wwin);
The function wUserMenuGet is used only in application.c, overriding
the previous call for appmenu (se above).
129 #ifdef USER_MENU
130 if (!wapp-menu)
131 wapp-menu = wUserMenuGet(scr, wapp-main_window_desc);
132 #endif
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 01/14] wmkeys compilation bugs
Carlos R. Mafra crma...@gmail.com escribió: On Sat, 15 Aug 2015 at 23:15:11 +, Rodolfo García Peñas (kix) wrote: Doug Torrance dtorra...@piedmont.edu escribió: On 08/15/2015 06:29 PM, Rodolfo García Peñas (kix) wrote: I modified all other dockapps. Thanks for doing this! The wmbiff dockapp includes a different wmgeneral library. This dockapp doesn't compile. I don't include this new code in libdockapps because include code of application that doesn't compile IMO is not a good idea. Probably we should try to compile the wmbiff dockapps, and then, think about include or not the three new functions in libdockapp. This is something I've looked at a little bit. I have a branch [1] with a partially working wmbiff which uses the shared wmgeneral library (after adding the wmbiff-specific functions to the library, as you mentioned). However, wmbiff is special in that it allows non-64x64 windows, and this is the main diverence from the main wmgeneral functions. I haven't gotten around to solving this issue yet. Doug [1] https://github.com/d-torrance/dockapps/tree/update-wmbiff Hi Doug, we can compile it with this little change in tlsComm.c: -struct connection_state *initialize_gnutls(UNUSED(int sd), +struct connection_state *initialize_gnutls(UNUSED(intptr_t sd), Could you write this one-liner as a standalone patch to the current repo? I've just checked here that it indeed fixes the compilation, and it is good to have this change separated from any others. Sure, I just sent the patch. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 01/14] wmkeys compilation bugs
Carlos R. Mafra crma...@gmail.com escribió: On Sun, 16 Aug 2015 at 0:22:49 +0200, Rodolfo García Peñas (kix) wrote: Thank you Rodolfo, the diffstat of this series is simply awesome! 88 files changed, 51 insertions(+), 11084 deletions(-) Thanks Carlos. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 01/14] wmkeys compilation bugs
Hi,
I modified all other dockapps.
The wmbiff dockapp includes a different wmgeneral library. This
dockapp doesn't compile. I don't include this new code in libdockapps
because include code of application that doesn't compile IMO is not a
good idea.
Probably we should try to compile the wmbiff dockapps, and then, think
about include or not the three new functions in libdockapp.
Cheers,
kix
Rodolfo García Peñas (kix) k...@kix.es escribió:
This patch solves a bug and a warning:
- The dockapp wmkeys uses the getline function, that is the same
function provided by stdio.h. This patch changes the function
name to getline_wmkeys.
- The main function returns void, and should return integer. This
patch includes the return 0 at the function end and it changes
the function prototype.
Signed-off-by: Rodolfo García Peñas (kix) k...@kix.es
---
wmkeys/wmkeys.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/wmkeys/wmkeys.c b/wmkeys/wmkeys.c
index 718ccd5..72d98e7 100644
--- a/wmkeys/wmkeys.c
+++ b/wmkeys/wmkeys.c
@@ -94,7 +94,7 @@ void enable_configuration(int n);
* Main
*/
-void main(int argc, char *argv[])
+int main(int argc, char *argv[])
{
num_configs = 0;
current_config = 0;
@@ -105,6 +105,8 @@ void main(int argc, char *argv[])
read_config();
wmkeys_routine(argc, argv);
+
+ return 0;
}
/*
@@ -179,7 +181,7 @@ void draw_string(char* s)
* getline()
*/
-int getline(FILE* pfile, char* s, int lim)
+int getline_wmkeys(FILE* pfile, char* s, int lim)
{
int c = 0, i;
for(i=0; ilim-1 (c=fgetc(pfile)) != EOF c!='\n'; ++i) {
@@ -226,10 +228,10 @@ void read_config()
}
while(!feof(pfile)) {
-getline(pfile, key, 256);
+getline_wmkeys(pfile, key, 256);
if(!feof(pfile)) {
- getline(pfile, value, 256);
+ getline_wmkeys(pfile, value, 256);
configs[num_configs].name = malloc(sizeof(char)*strlen(key)+1);
strcpy(configs[num_configs].name, key);
--
2.5.0
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] New library wmgeneral
Alexey I. Froloff ra...@raorn.name escribió: On Thu, Aug 13, 2015 at 05:42:41PM +0200, Rodolfo García Peñas (kix) wrote: This patch includes the library wmgeneral. Please, don't do it! There's already libdockapp, why would we need yet another _shared_ library with, like, five functions? What are you trying to fix? Does it really worth it? You only make things harder for a package maintainers. Better rewrite those applets to libdockapp. Hello, I think is done. I only included wmgeneral on libdockapp. Please, test it. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Build Errors
Ed Snyder dragonpalem...@gmail.com escribió: Hi Milan, Thanks for the info and help! I think I got it sorted out and working now. Thanks! Ed On Thu, Aug 13, 2015 at 1:31 PM, Milan Čermák mcer...@chello.cz wrote: Hi Ed, I've built WindowMaker Debian packages just yesterday and encountered this error, too. My take is that all manpages from section 1x were moved to section 1. So, the file wxpaste.1x was renamed to wxpaste.1 (and some others too). One other issue was that I had to apply debian patches manually (with dh_quilt_patch). The automatics that should have been in debian/rules just did not work. Hope this helps, Milan Hi, It's been awhile since I've been on here or even Window Maker for that matter. Currently trying to build wmaker packages from the GIT sources and having troubles. This is on Debian. --- cp: cannot stat ‘debian/tmp/usr/share/man/ru/man1/wxpaste.1x’: No such file or directory dh_install: cp -a debian/tmp/usr/share/man/ru/man1/wxpaste.1x debian/wmaker//usr/share/man/ru/man1/ returned exit code 1 debian/rules:50: recipe for target 'override_dh_install' failed make[1]: *** [override_dh_install] Error 2 make[1]: Leaving directory '/home/ed/Downloads/wmaker-crm-2db0449' debian/rules:39: recipe for target 'binary-arch' failed make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 --- It seems there are some missing files for Debian? This is not the only one either. Any help would be much appreciated! Thanks! Hi, I updated the debian stuff. Is ready to upload to the debian and ubuntu distros. For Debian, I will do it in some days. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Remove the phase2 variable
Hi,
The variable phase2 can be removed. Is only used in one place. This
patch is for awmaker, but probably it could be adapted to wmaker.
Cheers,
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
From 658e5cd52c791b1e0e56c2f20c3d13f745737fcb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20=28kix=29?=
k...@kix.es
Date: Mon, 20 Jul 2015 00:50:45 +0200
Subject: [PATCH] Removed w_global.startup.phase2 variable
The variable w_global.startup.phase2 can be removed because is used only
in the function wWorkspaceForceChange, so we can remove the call and the
if about this variable.
---
src/WindowMaker.h | 1 -
src/startup.c | 5 -
src/workspace.c | 2 +-
3 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 1f466a6..a72124a 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -502,7 +502,6 @@ extern struct wmaker_global_variables {
/* Window Maker startup phases */
struct {
unsigned int phase1:1;
- unsigned int phase2:1;
} startup;
/* locale to use. NULL==POSIX or C */
diff --git a/src/startup.c b/src/startup.c
index decea51..23f4cef 100644
--- a/src/startup.c
+++ b/src/startup.c
@@ -695,8 +695,6 @@ void StartUp(Bool defaultScreenOnly)
manageAllWindows(w_global.vscreens[j], wPreferences.flags.restarting == 2);
- w_global.startup.phase2 = 1;
-
while (XPending(dpy)) {
XEvent ev;
WMNextEvent(dpy, ev);
@@ -704,12 +702,9 @@ void StartUp(Bool defaultScreenOnly)
}
vscr-workspace.last_used = 0;
- wWorkspaceForceChange(vscr, 0);
if (!wPreferences.flags.noclip)
wDockShowIcons(vscr-workspace.array[vscr-workspace.current]-clip);
- w_global.startup.phase2 = 0;
-
/* restore saved menus */
wMenuRestoreState(w_global.vscreens[j]);
diff --git a/src/workspace.c b/src/workspace.c
index f4ff4a0..596ba8f 100644
--- a/src/workspace.c
+++ b/src/workspace.c
@@ -540,7 +540,7 @@ static void showWorkspaceName(virtual_screen *vscr, int workspace)
void wWorkspaceChange(virtual_screen *vscr, int workspace)
{
- if (w_global.startup.phase1 || w_global.startup.phase2 || vscr-screen_ptr-flags.ignore_focus_events)
+ if (w_global.startup.phase1 || vscr-screen_ptr-flags.ignore_focus_events)
return;
if (workspace != vscr-workspace.current)
--
2.1.4
Re: Malformed checkboxes in Window Attributes window
Alwin translati...@ziggo.nl escribió: Hi, Josip Deanovic schreef: Hi! Did anybody else notice the malformed look of checkboxes in Window Attributes window? Yes, but it's not malformed. The first (read-only) box indicates the window hint requested by the program. The second one is a tristate check box, that can be changed to override it. Some programs (GNOME/GTK?) might need it to run correctly under Window Maker. (See also the Help balloon, when hovering the first check box. It can also be used to remove the resize bar on some Window Maker panels, as they can't be resized currently. To turn the resize bar off in those panels by default, would look better imho: WPrefs panel, Color panel, and the panels for opening images/directories/programs. Hello, IMO, this new feature is terrible :-) I don't like it and is difficult to understand for an user. Is not intutive. The checkboxes don't have title or something like that show what they do. Really the user want to know the hint requested by the program? If the dialog.c/panels* needs handle titlebar, resizebar,... it could be implemented in the window.c/wCreateInternalWindow function. IMO, this feature should be removed and find new ideas for the problems. Cheers, kix PS: I had the same thought, malformed look of checkboxes in Window Attributes window I have attached the screenshot (~189KiB, PNG) which shows how it looks on my setup. Regards -- [alwin] -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/9] wmaker: moved the list of Application Attributes into an array, for the Window Inspector
Christophe CURIS christophe.cu...@free.fr escribió: The Window Inspector is used to let user change a list of advanced options for all the windows of an application. This list was defined through many hard-coded things; by defining an array with everything at the beginning of the file it is easier to maintain (the code is simpler because it is more generic) and to make it evolve. Signed-off-by: Christophe CURIS christophe.cu...@free.fr --- src/winspector.c | 116 +++ 1 file changed, 57 insertions(+), 59 deletions(-) Hi Christophe, these patches about move the hard coded things to an array are a great idea. Thanks a lot. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 15/23] doc: convert INSTALL-WMAKER into a texinfo source processed by texi2txt
Ok, I found the patch about mawk. Cheers, kix. Rodolfo García Peñas k...@kix.es escribió: On Mon, 06 Apr 2015, Christophe CURIS escribió: The source of the documentation is in Texinfo format to have the possibility someday to distribute in more format that just plain text; The INSTALL-WMAKER original file will now be generated automatically when running the 'autogen.sh' script (for those who made a git-checkout) and when running 'make' (for the people who create the distribution archive). The current document have seen these changes: - added all the texinfo header (including the copyright notice); - texinfo formatting command in place everywhere applicable; - re-ordering of the content to try to get a consistent document. Apart from this, the document should not have seen any change on the content, because this deserves dedicated patches to show the evolution. Signed-off-by: Christophe CURIS christophe.cu...@free.fr --- Hi, I have this problem with this patch: Making all in doc make[2]: Entering directory '/home/kix/src/wmaker/wmaker-crm/doc' Making all in build make[3]: Entering directory '/home/kix/src/wmaker/wmaker-crm/doc/build' if test ! -e ../../INSTALL-WMAKER -o -w ../../INSTALL-WMAKER ; then \ ../../script/generate-txt-from-texi.sh \ ./Compilation.texi -o ../../INSTALL-WMAKER \ -Dversion=0.95.6 -e wmaker-dev@lists.windowmaker.org ; \ else \ echo Warning: \../../INSTALL-WMAKER\ is not writeable, not regenerated ; \ fi Error: cross reference to undefined node/anchor ConfigureOptions found at line 246 Makefile:489: recipe for target '../../INSTALL-WMAKER' failed make[3]: *** [../../INSTALL-WMAKER] Error 3 make[3]: Leaving directory '/home/kix/src/wmaker/wmaker-crm/doc/build' Makefile:544: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/home/kix/src/wmaker/wmaker-crm/doc' Makefile:458: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/kix/src/wmaker/wmaker-crm' Makefile:393: recipe for target 'all' failed make: *** [all] Error 2 kix@debian:~/src/wmaker/wmaker-crm$ Cheers, kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
Johann Haarhoff joh...@haarhoff.org.za escribió:
Does anyone work on Wayland support in Window Maker?
I don't think is is possible. From the Wayland FAQ:
How can I replace Wayland's Window Manager
The Wayland architecture integrates the display server, window manager
and compositor into one process. You can think of Wayland as a toolkit
for creating clients and compositors. It is not a specific single
compositor or window manager. If you want a different window manager,
you can write a new one.
It will be an very difficult task to integrate wmaker into the same
process as wayland. Also
~/projects/wmaker$ grep -R \sX src/ WINGs/ wmlib/ wrlib/ WPrefs.app/ |
grep -iv binary | wc -l
4184
There are around ~4000 calls to X11 in wmaker, not a trivial task to
replace them.
Dear Window Maker developers,
I think this mail is related to my previous comments about the wmaker
abstraction. wmaker could continue running in Wayland, but not
natively, using an X11 server for Wayland. wmaker needs X11 to run.
Now, I am busy with other projects and I (now) cannot continue with my
wmaker branch (https://github.com/awmaker/awmaker). I will continue in
the future with it, but I would like to share my first impressions
with my fork/branch. These tips could help you to improve wmaker and
include Wayland or non-X11 support.
1. The wmaker uses WScreen struct to handle all objects. WScreen is
X11 realted object. For example, for a window, this is the code. The
code for all objects is the same, a pointer to WScreen:
src/window.h:
177 typedef struct WWindow {
178 struct WWindow *prev; /* window focus list */
179 struct WWindow *next;
180
181 WScreen *screen_ptr; /* pointer to the screen structure */
2. When wmaker starts, it creates a different WScreen struct for every
X11 screen.
3. Using the previous dots (1 and 2):
a. When wmaker is restarted, all items must be destroyed and
recreated. Because the WScreen struct is destroyed and re-created.
b. Are not possible make X11 screen changes without restart wmaker.
Wmaker doesn’t support screen swapping, screen changes, screen attach
and de-attach in laptops… wmaker depends on X11 configuration. No
support for different window systems (Wayland,...), at least native
support.
c. Behaviors using “Xinerama”, “XRandR” and multiple independent
screens are different. The windows, the WDock, the Clip,… belongs to
an WScreen. The number of WDock, Clips,… is fixed.
d. Items position in the WScreen is complex. Every item (Dock,
Clip, Menu, Window …) has their own method to display it.
What I am doing?:
The method I am using is easy. I split the WScreen struct in two
different structs:
WScreen: Hardware related info.
virtual_screen: Non-hardware related info
Items are painted in the virtual_screen, not in the WScreen.
wmaker has two different arrays (or lists) one for WSCreens and other
for virtual_screens. When wmaker starts, it binds the previously
created virtual_screens to the real screens (WScreen structs). If
virtual_screens are cero, wmaker is starting, and new virtual_screens
must be created, one per WScreen. But if the virtual_screen array is
not cero (XConfigure event, wmaker restart...), we should bind these
virtual_screens to the WScreens.
We could have the same virtual_screens that WScreens (or more!, or
less!). If more, we have virtual screens hidden, like the workspaces…
But the main tip is, we can restart wmaker, swap the screens, connect
or disconnect screens,... Because the items are painted to the
virtual_screen, we can use the same functions to found the right
position in the screen.
I did a lot of changes to do it. Now the items are created and hidden,
not destroyed. I removed the brother menu in the menu struct,...
OTOH, I split the functions in X11 related code and abstract (no
window system related). To change the code to Wayland, we need rewrite
only the X11 related functions.
I tried to upload the wmaker upstream changes to the awmaker code, to
re-join both projects in the future, so see the differences could be
easy.
The code is there, and this mail tries to explain the main ideas. Feel
free to implement them in wmaker. If you need help, write me or to the
list.
As I said, I will continue with the fork, but I have no time now.
git: https://github.com/awmaker/awmaker
I have more patches in my laptop, but I need time to upload them. I
someone is interested, I could try to upload them soon.
Cheers,
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
Quoting BALATON Zoltan bala...@eik.bme.hu: Hello, ... screen and so on. Are you sure it's not more complex than you think and you've considered all scenarios and not trying to build on overly simpified assumptions? Regards, BALATON Zoltan Hi, thanks a lot for your reply. I will try to reply you later again, with more info. I have (or I am working on them) different functions (I will upload my current laptop code these days). For example, for titlebar, I have (is only an example): - titlebar_create(): Create the core struct, without WScreen info. - titlebar_destroy(titlebar): Destroy the core struct, if the titlebar is mapped on the screen, unmap it first. - titlebar_map(titlebar, WScreen): Show the titlebar in the WScreen (paint to X11) - titlebar_unmap(titlebar): Hide the titlebar. Really, the WScreen info is used from virtual_screen-WScreen. For example, in my code, the menu core contains the text, the relationship between menus and submenus, but not the decorations. The decorations are painted in the menu_map() function. Move elements between screens could be done using unmap+map. Again, thanks a lot for your reply. Regards, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about nopolling variable
Christophe christophe.cu...@free.fr escribió: - Rodolfo García Peñas k...@kix.es a écrit : Hi, I have a question about the variable nopolling. Is used? Could we remove it? I found it in src/startup.c, but the variable is never set. I am missing something? Hi, Not that I'd want to revive an old topic (okay, not that old, only a week old), but from a little investigations, I would tend to give my 100% vote on removing it. It is a duplicate of the noupdate flag, they both were designed to do the same thing, with the different that nopolling was never implemented properly; and that I believe noupdate is a little bit closer to what the function really is. So, my feeling is: Go! (just polish up the commit message and that'll be über-wonderful) Thanks a lot Christophe, could you do it? Or you prefer I create the patch? Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
GLOBAL_SUBMENU_FILE definition
Hi,
I found these lines:
1543 #ifdef GLOBAL_SUBMENU_FILE
1544 if (includeGlobals) {
1545 WMenu *submenu;
1546 WMenuEntry *mentry;
1547
1548 submenu = readMenuFile(scr, GLOBAL_SUBMENU_FILE);
1549
1550 if (submenu) {
1551 mentry = wMenuAddCallback(menu, submenu-frame-title, NULL, NULL);
1552 wMenuEntrySetCascade(menu, mentry, submenu);
1553 }
1554 }
1555 #else
1556 /* Parameter not used, but tell the compiler that it is ok */
1557 (void) includeGlobals;
1558 #endif
The variable GLOBAL_SUBMENU_FILE is never defined (I did a rgrep).
IMO, we should remove lines 1543-1558 and remove the variable
includeGlobals as argument in the function configureMenu.
What do you think?
Cheers,
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about nopolling variable
Carlos R. Mafra crma...@gmail.com escribió: On Mon, 8 Dec 2014 at 17:46:25 +, Rodolfo García Peñas (kix) wrote: Carlos R. Mafra crma...@gmail.com escribió: On Mon, 8 Dec 2014 at 16:28:14 +0100, Rodolfo García Peñas wrote: On Mon, 08 Dec 2014, Carlos R. Mafra escribió: On Mon, 8 Dec 2014 at 13:36:25 +0100, Rodolfo García Peñas wrote: Hi, I have a question about the variable nopolling. Is used? Could we remove it? I found it in src/startup.c, but the variable is never set. I am missing something? Thanks, kix kix@debian:~/src/wmaker/awmaker$ rgrep nopolling * NEWS:Running Window Maker with one of -nopolling or --no-polling command line src/startup.c: if (!wPreferences.flags.nopolling !wPreferences.flags.noupdates) src/WindowMaker.h: unsigned int nopolling:1; /* don't poll the defaults database for changes */ kix@debian:~/src/wmaker/awmaker$ [mafra@linux-g29b:wmaker.git]$ git grep -B 2 nopolling NEWS-- NEWS- NEWS:Running Window Maker with one of -nopolling or --no-polling command line -- src/WindowMaker.h-unsigned int norestore:1; /* don't restore session */ src/WindowMaker.h-#ifndef HAVE_INOTIFY src/WindowMaker.h:unsigned int nopolling:1; /* don't poll the defaults database f or changes */ -- src/startup.c-#ifndef HAVE_INOTIFY src/startup.c-/* setup defaults file polling */ src/startup.c:if (!wPreferences.flags.nopolling !wPreferences.flags.noupdates) [mafra@linux-g29b:wmaker.git]$ Yes, but the variable is never set, therefore the if in src/startup.c is always true. IMO we can remove this variable. I see. The issue here seems to be that the command line option --no-polling sets the variable noupdates instead of nopolling (see src/main.c). In principle these two variables should be distinct, I'm not sure if we can actually merge the two concepts. Hi, the feature was added here: http://repo.or.cz/w/wmaker-crm.git/commit/4637c09d19570050158851109d9df92e3c18db58 And removed here: http://repo.or.cz/w/wmaker-crm.git/commitdiff/722c82c8ab50f3f6efe62b5897a69547c04e0f81 Do you remember something about this patch? I do. In the commit 722c82c8 I removed the variable completely. Commit c7868fa4 added it back but made the -no-polling option set the noupdates variable instead of nopolling. Perhaps that was not intended. Ok, but in your oppinion what is the better way to finish with this point? Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] wmaker: Restore multi screen functionality by reverting wrong commits
Hello,
please, how can I reproduce the problem?
Thanks a lot,
Rodolfo.
BALATON Zoltan bala...@eik.bme.hu escribió:
Revert patches that moved variables from WMScreen to global level
because this broke X displays with multiple independent screens and
caused dock and clip icons to become mixed up. When managing multiple
screens each screen used to have it's own state/dock and clip. This
commit restores that by reverting mainly the commits listed below (and
those that are invalidated by reverting these) and fixing up later
commits to apply after the revert.
Reverted commits:
f60e65001bfdd21fd9939b2b0121037682b6522c Moved 'workspace_name_font'
from the Screen to a Workspace object in the global namespace
9e103a46e99d323e070c3779c5d261c171df2e17 Variable workspace_count
moved to the workspace object in the global namespace
e5ae684d02fdb66f1a90d486a21fd70498464f90 Variable last_workspace
moved to workspace object in global namespace
c610b8d7ce865938a7a5e2aa97772f2a67f30602 Variable current_workspace
moved to workspace object in global namespace
f0c50736001dd8c5a81ab1ae5926f6e14b7a9730 Array of workspaces moved
to the workspace object in the global namespace
9c252988f8378876b9710561428666799317673c Variable workspace_menu
moved to workspace object in global namespace
e86b8dcb2f28bf06ff04e12ea15754b684437f31 Clip, Dock and Drawers menu
moved to appropriate global namespace
074092f319706bfe3f4df8873aab962ece25e9c3 Removed WScreen args not used
4a7daf2322901ca43b5cea2cab26015394db5b95 AppIcon list moved out of WScreen
2103fe390b839c2eea6a288539c5bd1c43435ac7 Variable clip_icon moved to
clip object in the global namespace
014bc52531ec5d554920ce82d3e1046e26f84a3b wClipIconPaint appicon
argument removed
40e1ea08b86a9d77488f451588581bacb794fdb2 Varible session_state moved
to global namespace
6987d4aa4041f17f31e05d677326b42b01f946de Removed WScreen argument
0de3e590cedeb441d7c5038b8fae26bf851c5fd8 shortcutWindows moved to w_global
2e64831fb6742d8fc4164000da9acae4738853a8 Removed unused variable wapp_list
b6423a7b4f0111f73690d2a99ca0433d30b5dd32 wmaker: Moved variable
Screen Count into the global namespace
---
src/WindowMaker.h | 52 ++--
src/actions.c | 56 ++---
src/appicon.c | 60 ++---
src/application.c | 17 +++-
src/balloon.c | 6 +-
src/cycling.c | 2 +-
src/defaults.c| 32 +++
src/defaults.h| 2 +-
src/dock.c| 198 ++-
src/dock.h| 6 +-
src/dockedapp.c | 4 +-
src/event.c | 59 ++---
src/main.c| 2 +-
src/menu.c| 13 +--
src/misc.c| 2 +-
src/moveres.c | 40 -
src/placement.c | 6 +-
src/rootmenu.c| 12 +--
src/screen.c | 37 -
src/screen.h | 29 +++
src/session.c | 67 ---
src/session.h | 2 +-
src/startup.c | 12 +--
src/switchmenu.c | 6 +-
src/switchpanel.c | 2 +-
src/wdefaults.c | 4 +-
src/window.c | 63 +++---
src/winmenu.c | 65 ---
src/winspector.c | 17 ++--
src/wmspec.c | 36
src/workspace.c | 245
+++---
src/workspace.h | 6 +-
src/xdnd.c| 2 +-
33 files changed, 589 insertions(+), 573 deletions(-)
diff --git a/src/WindowMaker.h b/src/WindowMaker.h
index 92e1ba6..82188bd 100644
--- a/src/WindowMaker.h
+++ b/src/WindowMaker.h
@@ -511,43 +511,12 @@ extern struct wmaker_global_variables {
/* Screens related */
int screen_count;
- /* Workspace related */
- struct {
- struct WWorkspace **array; /* data for the workspaces */
-
- int count; /* number of workspaces */
- int current;/* current workspace number */
- int last_used; /* last used workspace number */
-
- WMFont *font_for_name; /* used during workspace switch */
-
- /*
-* Ignore Workspace Change:
-* this variable is used to prevent workspace switch while
certain
-* operations are ongoing.
-*/
- Bool ignore_change;
-
- /* Menus */
- struct WMenu *menu; /* workspace operation */
- struct WMenu *submenu; /* workspace list for window_menu */
- } workspace;
-
- /* Clip related */
- struct {
- struct WAppIcon *icon; /* The clip main icon, or the dock's, if
they are merged */
-
- struct WMenu *menu; /* Menu for clips */
- struct WMenu *submenu; /* Workspace list for clips */
- struct WMenu *opt_menu; /* Options for Clip */
- struct WMenu *ws_menu; /* workspace menu for clip */
- } clip;
-
- /* Dock related */
- struct {
- struct WMenu *pos_menu; /* menu for position of the
Re: [PATCH 00/13] A bunch of small stuff for #next
Christophe christophe.cu...@free.fr escribió: From: Christophe CURIS christophe.cu...@free.fr Hello, These 13 patches are small improvements to the patches that are currently the #next branch. As I believe none of these deserve a separated commit, I have listed in each message the reference commit to witch the patch could be merged into. The patches are in reverse order compared to the commits in #next so that if they are merged one by one the commit number in reference should stay valid. Carlos, if you think any of these patch would require a dedicated commit in the history, feel free to skip that patch and let me know, I'll propose a new patch with a long message. Regards, Christophe. Hello, these patches were included in the repo? Thanks. Rodolfo. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 00/13] A bunch of small stuff for #next
Carlos R. Mafra crma...@gmail.com escribió: On Thu, 6 Nov 2014 at 9:35:53 +, Rodolfo García Peñas (kix) wrote: these patches were included in the repo? yes Sorry Carlos, but I cannot see them :-? I am missing something? In the #next branch, from 0.95.6 to HEAD, I can see these patches. From Christophe are patches about WPrefs. Thanks for your reply. Rodolfo. 43 hours agoDoug Torrance WINGs: Link examples against Xlib.next 3 days ago Doug Torrance WINGs: Avoid cast from pointer to integer of different... 3 days ago Doug Torrance WINGs: Fix unused parameter compiler warnings in examples. 3 days ago Doug Torrance WINGs: Fix decimal/hexadecimal conversion bug in color... 3 days ago Christophe... WPrefs: use length of array instead of hard-coded const... 3 days ago Christophe... WPrefs: grouped items related to the possible window... 3 days ago Christophe... WPrefs: grouped items related to the behaviour of movin... 3 days ago Christophe... WPrefs: grouped items related to the AppIcon bouncing... 3 days ago Christophe... WPrefs: grouped items related to the help balloon confi... 3 days ago Christophe... WPrefs: grouped items related to the window title align... 3 days ago Christophe... WPrefs: grouped items related to the menu style in... 3 days ago Christophe... WPrefs: replaced a few constants by the macro 'wlengthof' 3 days ago Christophe... WPrefs: created macro 'wlengthof_nocheck' for the cases... 3 days ago Christophe... wrlib: add support for release 5.1.0 of the libgif 3 days ago Christophe... util: removed usage of external '__progname' because... 3 days ago Christophe... configure: add detection for 'nanosleep' function with... 3 days ago Milan Čermákwmaker: remove call to internal X11 header 3 days ago Milan Čermákwrlib: fix usage of deprecated attribute for gcc 3.x 3 days ago Christophe... util: clarify error message in wmaker.inst in case... 3 days ago BALATON Zoltan wmaker: Restore multi screen functionality by reverting... 3 days ago Khaled HosnyWINGs: Add optional Pango text layout support 3 days ago David Maciejak wmaker: fix maximizing window in multiple screens env 3 days ago David Maciejak WINGs: add function to get button caption 3 days ago David Maciejak wmaker: fix arbitrary shell command injection 3 days ago Doug Torrance Update ChangeLog, from version 0.92.0+ to most recent... 3 days ago Doug Torrance Add script to update ChangeLog from git log. 3 days ago Doug Torrance wmaker: Consistent whitespace in WindowMaker.h. 3 days ago Doug Torrance wmaker: Add more directions for window snapping. 3 days ago Doug Torrance NEWS: Add note about dragging maximized windows. 3 days ago Doug Torrance WPrefs.app: Add ability to set behavior when dragging... 3 days ago Doug Torrance wmaker: Add new options for dragging maximized windows. 3 days ago Amadeusz Sławiński fix maximize when dock is set 'on top' and it should... 3 days ago Doug Torrance NEWS: Add note about window snapping. 3 days ago Doug Torrance WPrefs.app: Add ability to enable or disable unmaximiz... 3 days ago Doug Torrance wmaker: Add unmaximize on move feature. 3 days ago Doug Torrance wmaker: Clear maximized flag of a maximized window... 3 days ago Doug Torrance WPrefs.app: Add ability to enable or disable window... 3 days ago Doug Torrance wmaker: Add window snapping feature. 3 days ago David Maciejak util: create custom GNUSTEP dir if needed 3 days ago David Maciejak wmaker: add clip mouse wheel action to change workspace 3 days ago David Maciejak wmaker: improve windows listing in switchpanel 3 days ago Doug Torrance wmaker: Remove dead links from BUGFORM. 3 days ago David Maciejak WPrefs: add new mouse actions configuration 3 days ago David Maciejak wmaker: add new button and wheel mouse actions 3 days ago David Maciejak wmaker: use defined wWindowSingleFocus() function 3 days ago David Maciejak wmaker: add next and previous window focus functions 3 days ago David Maciejak WPrefs: set default to 1st color in gradient texture 3 days ago David Maciejak wmaker: update NEWS for 0.95.6 Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 00/13] A bunch of small stuff for #next
Carlos R. Mafra crma...@gmail.com escribió: On Thu, 6 Nov 2014 at 10:33:43 +, Rodolfo García Peñas (kix) wrote: Carlos R. Mafra crma...@gmail.com escribió: On Thu, 6 Nov 2014 at 9:35:53 +, Rodolfo García Peñas (kix) wrote: these patches were included in the repo? yes Sorry Carlos, but I cannot see them :-? I am missing something? In the #next branch, from 0.95.6 to HEAD, I can see these patches. From Christophe are patches about WPrefs. They were merged into previous ones, as their commit log suggested. So the only way to realize they are in the repo is to look at the source code and see that their changes are there. There are no commits associated to them. Ok. Thanks. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Problem with stacking
David Maciejak david.macie...@gmail.com escribió: Hi, I also stumbled upon the same issue (I put the old email in reference below) and dug into it these last days. Rodolfo, as you were the original reporter. Could you please check the patch enclosed ? thanks! david Hi David, you made my day :-) Patch is perfect. Thanks a lot, Rodolfo. From e1e12067794c4e53064e59edc3de7af196179369 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20(kix)?= k...@kix.es Date: Sat, 23 Jun 2012 15:21:24 +0200 Subject: [PATCH] Test environment Hi, we have a bug with stacking. If you check your logfile (~/.xsessions-errors) or the console y you are not using a visual login program (xdm, kdm, gdm,...), you will find something like: wmaker(catchXError(startup.c:177)): warning: internal X error: RenderBadPicture (invalid Picture parameter) Request code: 152 Request minor code: 7 Resource ID: 0x6000a4 Error serial: 9269 This output is created when you deminiaturize a window using double-click. Yes, try now! :-) I spent some time on this problem, but I cannot solve it. I saw an interesting thing. When you minimize the window and then deminiaturize with double click you get the problem. But, if you minimize the window and then deminiaturize it with rigth click on the icon, and then click on deminiaturize, then you don't get the error. Ok, I continue checking the problem, and I created a Testing enviroment patch (attached). With this patch, I got this output: --win 0x1a12dd0-- 1 2 5 wmaker(catchXError(startup.c:177)): warning: internal X error: RenderBadPicture (invalid Picture parameter) Request code: 152 Request minor code: 7 Resource ID: 0x6000a4 Error serial: 9269 --win 0x1a499b0-- -.win 0x1a12dd0.- 2 5 -.win 0x1a12dd0.- When I deminiaturize the icon using double click, then if (frame-stacking-under) is true, but using the miniwindow menu, the flow is different, and it don't exec the stacking line frame-stacking-under-stacking-above = frame-stacking-above;. The question is easy, why the frame-stacking-under exists if I did double click? Finally, if you see the lines above and below the call to wDeiconifyWindow (printf(--win %p--\n and printf(-.win %p.-\n, the WWindow address is the same using the menu and different using double click. Any help is appreciated. Best Regars, kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Could we remove this code?
Hi,
is possible remove this code? I did it and no differences :-/
Cheers,
kix
kix@kentin:~/src/wmaker-crm$ git diff
diff --git a/src/dock.c b/src/dock.c
index e837280..2f394d7 100644
--- a/src/dock.c
+++ b/src/dock.c
@@ -3250,29 +3250,6 @@ void wDockTrackWindowLaunch(WDock *dock, Window window)
icon-main_window = window;
}
found = True;
- if (!wPreferences.no_animations !icon-launching
- !dock-screen_ptr-flags.startup
!dock-collapsed) {
- WAppIcon *aicon;
- int x0, y0;
-
- icon-launching = 1;
- dockIconPaint(icon);
-
- aicon =
wAppIconCreateForDock(dock-screen_ptr, NULL,
-
wm_instance, wm_class, TILE_NORMAL);
- /* XXX: can: aicon-icon == NULL ? */
- PlaceIcon(dock-screen_ptr, x0, y0,
wGetHeadForWindow(aicon-icon-owner));
- wAppIconMove(aicon, x0, y0);
- /* Should this always be lowered? -Dan */
- if (dock-lowered)
- wLowerFrame(aicon-icon-core);
- XMapWindow(dpy, aicon-icon-core-window);
- aicon-launching = 1;
- wAppIconPaint(aicon);
- SlideWindow(aicon-icon-core-window,
x0, y0, icon-x_pos, icon-y_pos);
- XUnmapWindow(dpy, aicon-icon-core-window);
- wAppIconDestroy(aicon);
- }
wDockFinishLaunch(icon);
break;
}
kix@kentin:~/src/wmaker-crm$
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] wmaker: src/action.c merge duplicate code
David Maciejak david.macie...@gmail.com escribió:
No problem i understand, enclosed the new patch.
Hi David,
is possible remove the extra curly brackets (in both ifs)?:
+ if (getAnimationGeometry(wwin, ix, iy, iw, ih)) *{*
animateResize(wwin-screen_ptr, ix, iy, iw, ih,
wwin-frame_x, wwin-frame_y,
wwin-frame-core-width,
wwin-frame-core-height);
*}*
Thanks a lot for your patches.
Best regards,
Rodolfo.
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] wmaker: src/action.c merge duplicate code
Rodolfo García Peñas (kix) k...@kix.es escribió:
David Maciejak david.macie...@gmail.com escribió:
No problem i understand, enclosed the new patch.
Hi David,
is possible remove the extra curly brackets (in both ifs)?:
Hi again,
Perhaps we can change this if from the negative way to possitive way:
+ if (!wwin-screen_ptr-flags.startup !wPreferences.no_animations
+!wwin-flags.skip_next_animation wwin-icon != NULL) {
to
+ if (wwin-screen_ptr-flags.startup || wPreferences.no_animations ||
+ wwin-flags.skip_next_animation || wwin-icon == NULL) {
Then we can return earlier:
+ if (wwin-screen_ptr-flags.startup || wPreferences.no_animations ||
+ wwin-flags.skip_next_animation || wwin-icon == NULL)
+ return 0;
And then add the rest of the code with less tabs:
+ if (!wPreferences.disable_miniwindows
+!wwin-flags.net_handle_icon) {
+ *ix = wwin-icon_x;
+ *iy = wwin-icon_y;
+ *iw = wwin-icon-core-width;
+ *ih = wwin-icon-core-height;
+ } else {
+ if (wwin-flags.net_handle_icon) {
+ *ix = wwin-icon_x;
+ *iy = wwin-icon_y;
+ *iw = wwin-icon_w;
+ *ih = wwin-icon_h;
+ } else {
+ *ix = 0;
+ *iy = 0;
+ *iw = wwin-screen_ptr-scr_width;
+ *ih = wwin-screen_ptr-scr_height;
+ }
+ }
+ return 1;
+}
What do you think? Perhaps could be an idea to add in a different
patch, following the Carlos recommendation about git bisect,...
Cheers,
kix.
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker Fork
David Maciejak david.macie...@gmail.com escribió: On Monday, August 18, 2014, Josip Deanovic djosip+n...@linuxpages.net wrote: Quoting message written on Sunday 2014-08-17 18:07:08 by Charles Philip Chan: On 17 Aug 2014, k...@kix.es javascript:; wrote: Hi Kix: I was thinking about create a Window Maker fork, and probably is the best way to contribute to Window Maker. My aim now is include XRandR, Multihead and hardware abstration for Window Maker, but this is very difficult because we need include a lot of changes and Window Maker could be unstable. Why a fork instead of an experimental branch? Charles Indeed, why? That would only create a confusion. Hi, I believe we all want these features to be part of the future of Window Maker, but creating a fork will, in my opinion, also split the workforce. I am a great fan of GitHub, but as you may know not a pure git expert. Anyway, an unstable branch, whichever wmaker version it will be, could be created and some extended perms could be granted to ppl who want to lead the next major version ? I discovered earlier today that there is already a github for wmaker at https://github.com/crmafra/wmaker Why not using it ? Regards, David Hi David, Josip, Charles, I don't want to reopen old wounds, but perhaps I should reply your mails. I had some disagreements some time ago. Github repo was created then. For me, write wmaker code is a hobby. I don't want problems, I want play. I had more than 200 patches here and probably some people could be interested on them. For this reason I uploaded the patches to github. I changed the name to awmaker and included a new README file to avoid confusion. Best regards, Rodolfo. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Window Maker Fork
Hi, I was thinking about create a Window Maker fork, and probably is the best way to contribute to Window Maker. My aim now is include XRandR, Multihead and hardware abstration for Window Maker, but this is very difficult because we need include a lot of changes and Window Maker could be unstable. I created a new fork in github [1]. You are invited to help. I included a lot of patches, and there are a lot of work to do. Your help is very appreciated. I will continue packaging wmaker for Debian, of course. Window Maker is a very good Window Manager, awmaker is only a development branch. Probably we can merge both in the future. Finally, awmaker and Window Maker share WINGs, wraster,... I would like to remove them in awmaker, please, work together. Cheers, kix [1] https://github.com/awmaker/awmaker Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] wmaker: switch back icon name to the window name when needed
Hi David, really, nice patch. Probably we should include this change some time ago. I remember this problem. Perhaps you can read this [1] thread about it, there are more ideas like use other atoms, but with your change mostly applications set the icon title. [1] (Help with Atom (window/icon titles)) http://lists.windowmaker.org/dev/thrd42.html#04163 Cheers, kix David Maciejak david.macie...@gmail.com escribió: As reported by Charles some days ago, some apps like okular or vlc are not setting an icon name. This patch is setting the icon name to the window name when _NET_WM_ICON_NAME is not provided by the app. --- src/icon.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/icon.c b/src/icon.c index 1aa27ea..e1321fa 100644 --- a/src/icon.c +++ b/src/icon.c @@ -328,10 +328,12 @@ void wIconChangeTitle(WIcon *icon, WWindow *wwin) if (icon-icon_name != NULL) XFree(icon-icon_name); - /* Set the new one, using two methods */ + /* Set the new one, using two methods to identify + the icon name or switch back to window name */ icon-icon_name = wNETWMGetIconName(wwin-client_win); if (!icon-icon_name) - wGetIconName(dpy, wwin-client_win, icon-icon_name); + if (!wGetIconName(dpy, wwin-client_win, icon-icon_name)) + icon-icon_name = wNETWMGetWindowName(wwin-client_win); } RImage *wIconValidateIconSize(RImage *icon, int max_size) -- Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Patches for wmmon
Hi, I have a question about include some patches in wmmon. Pedro sent some patches to Debian BTS (see [1]). Patches are nice, but they have some things that I am not sure if they are ok for us. My comment is about the change from CC to GCC compiler and use gcc specific definitions: 1. Change the CC compiler to gcc (wmmon-1.1%2B20120402.patch [2]) 2. Usage the llong, perhaps gcc specific [2] 3. Include a new file in the library wmgeneral. I think wmgeneral is a common library. Perhaps we should create a new library libwmgeneral in the dockapps repo and link/include the dockapps to them (see wmSMPmon, wmbiff, wmckgmail,wmitime, wmmon,...). kix [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670151 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=wmmon-1.1%2B20120402.patch;att=1;bug=670151 Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/3] Some stuff
Hi, some comments: Christophe christophe.cu...@free.fr escribió: From: Christophe CURIS christophe.cu...@free.fr Hello, Nothing revolutionary in the series: - patch 1 is a re-send of Ioan Moldovan's patch, which look like have been stuck by gmail's spam filter. I took the opportunity to improve the commit message and do some aspect-only changes. Please note that I have not tested the patch yet, but I guess it will finally fix an annoying behaviour; IMO, the patches should be tested before uploaded. This patch doesn't follow the style (emtpy lines, spaces between the operators). - patch 2 reverts a small change to keep API compatibility (both header and binary level) for WRaster library; - patch 3 is boring stuff in preparation of a future release (any planned?) Is possible split the libraries and the wmaker code in different repos? Regards, kix Regards, Christophe. WINGs/WINGs/WINGs.h | 2 +- configure.ac| 12 ++-- src/moveres.c | 20 +++- wrlib/wraster.h | 27 ++- 4 files changed, 48 insertions(+), 13 deletions(-) -- 2.0.1 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Windowmaker 0.95.5 Unexpected behavior: Mini-icon issue: No title for QT Apps.
Al Zheimer alzhei...@digitalsook.net escribió: Greetings, Windowmaker developers, First let me tell you how happy I am to see people (especially developers) still having interest in such a great window manager. The version 0.95.5 runs great, so thanks a lot for the great work! There's an unexpected behaviour I'd like to submit to you: Mini-icon's titles are empty with minimized QT applications. Steps to reproduce: - Launch a QT application (example: Clementine, Skype, Dolphin, Amarok, konsole, whatever that uses QT...) - Minimize it - The mini-icon has no title Same problem here. I am very busy now. Al, can you test it with previous wmaker versions (0.95.4,...) Cheers, kix Expected behaviour: Mini-icon's title should be the same as the application window title. The version of Windowmaker I'm using is 0.95.5 installed for my distro's repository, so I didn't compile it from the sources. However I'll be happy to do it if you think it may solve the issue. Any suggestions are welcomed, Thanks again for the great work, Best, Al. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Unable to build from source
Hi, the commit http://repo.or.cz/w/wmaker-crm.git/commitdiff/e74afba8d7e7e8f003735208be30328bd5d2ce25 makes that wmaker cannot compile now. The problem is here (see that the msgid , and the previous line, is now dup): #: ../src/dialog.c:1527 msgid -Window Maker is free software; you can redistribute it and/or\n -modify it under the terms of the GNU General Public License as\n -published by the Free Software Foundation; either version 2 of the\n -License, or (at your option) any later version.\n +#: ../src/dialog.c:1417 +msgid +Window Maker 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.\n \n Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Github repository
Carlos R. Mafra crma...@gmail.com escribió: [snip] I don't want disturb you. You are just rioting in the mailing list for no reason and creating disharmony between us, also for no good reason. [snip] _You_ are not complying with the established rules and you have already But, where are the rules? Who wrote the rules? Who can change them? shown that you are not willing to cooperate and you are actively trying to create confusion in the wmaker-dev list in the past weeks. I am not creating confusion in the list. I am trying to change things. But, you don't agree with the changes. Why you don't reply other mails? Why you don't reply Christian? Why you don't reply Haroldo, or Paul? Is better say Rodolfo is bad, Rodolfo is rioting the mailing list and don't enter in the real questions. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Github repository
On 17/11/2013 13:44, Carlos R. Mafra wrote: On Sun, 17 Nov 2013 at 11:45:23 +0100, Rodolfo García Peñas (kix) wrote: On 17/11/2013 9:37, Carlos R. Mafra wrote: On Sat, 16 Nov 2013 at 23:39:18 +0100, Rodolfo García Peñas wrote: On Thu, 14 Nov 2013, Carlos R. Mafra escribió: I created a wmaker repository in github, https://github.com/crmafra/wmaker I will keep both the old repo.or.cz and the new github updated. Thanks, I am testing it. I sent some patches. Please send the patches to the mailing list. But, If I sent the patches to the mail list, nothing changes. What do you mean by nothing changes? Nothing. My english is too bad, but you cannot understand the difference between you and we. Your project, our project. When you send the patch to the mailing list many more people see it and are able to comment on it just by replying a plain text email (that's why the patches must be in the body of the email). That's the purpose of a development mailing list! I thought the idea with github was to have a bug tracking system, not that one could make the visibility of patches lower. If github is only a BTS, we don't use the code review Code review is easy to do over email, that's how things have always worked with many open source projects. I think having the repo in github is a good idea only because John never set up a BTS in www.windowmaker.org. ironic mode onkill John!!ironic mode off nor have our repos for other ideas. Why not? Everybody here in the mailing list have their own repos already in their own machines, that's the nature of distributed development. They develop their own ideas and then send patches, and most of this happens in the privacy of their own machines. Because my local repo is mine and nobody can see it?! _If_ they want to have their ideas in the open, they can have their own repos in github or anywhere else. But that is independent of whether the main wmaker repo is in github or not. Yes, I understand the idea. My code therefore is there. https://github.com/thekix/wmaker I will upload my work there. If you think my code is ok for *your* project, include it. So this argument does not make sense to me. Furthermore, I noticed in your patches that I'd like to fix some typos in the commit logs and to include the WPrefs: prefix in the patch that touches only WPrefs. That will make your repository no longer be in sync with mine after I do that. Yes, my main problem is typos in the commit logs. Other people send patches without commit. It's my fault. For that reason I would think that developing in your own temporary branches (that are later discarded) is more efficient, but everybody has their own workflows and it's ultimately their decision. But again, that is independent of whether the main wmaker is in github or not. Patches belong to the mailing list for everybody to see. I will work in the Debian wmaker package. I will report new bugs here, in the mail list, because That's the purpose of a development mailing list! Thanks and bye. Rodolfo (kix). -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Github repository
On 17/11/2013 17:24, Christian wrote: Hey guys, please calm down. :) My reply. Having code in github is a great idea. +1 You can branch, make changes and submit your code via 'merge requests'. +1 Anybody who is interested to see code changes should then add 'wmaker' to his watch list. Or try to get merge requests automatically mailed to the dev-mailing list and everybody would be happy. +1 I personally think it is an overhead to submit twice. Once as a merge request to wmaker and second mailing it here too. Or just post the link to the merge request here and discuss it. +1 What do you think ? work twice don't make sense. Cheers Chris Am 17.11.2013 15:53, schrieb Carlos R. Mafra: On Sun, 17 Nov 2013 at 14:34:06 +0100, Rodolfo García Peñas (kix) wrote: On 17/11/2013 13:44, Carlos R. Mafra wrote: On Sun, 17 Nov 2013 at 11:45:23 +0100, Rodolfo García Peñas (kix) wrote: On 17/11/2013 9:37, Carlos R. Mafra wrote: On Sat, 16 Nov 2013 at 23:39:18 +0100, Rodolfo García Peñas wrote: On Thu, 14 Nov 2013, Carlos R. Mafra escribió: I created a wmaker repository in github, https://github.com/crmafra/wmaker I will keep both the old repo.or.cz and the new github updated. Thanks, I am testing it. I sent some patches. Please send the patches to the mailing list. But, If I sent the patches to the mail list, nothing changes. What do you mean by nothing changes? Nothing. My english is too bad, but you cannot understand the difference between you and we. Your project, our project. Again, wmaker is not my project. I guess my agreed-upon status is the maintainer of wmaker, just like you are the maintainer of the wmaker package in the Debian repository. Is the wmaker debian package _your_ project? Or do you consider yourself doing a service to others by being the maintainer of that code in the best possible way as to please the majority of Debian users? The maintainer status is not for life though. If people feel that I'm not capable for maintaining wmaker (for whatever reason) then we can start to discuss who the next maintainer should be and I get out. https://github.com/thekix/wmaker I will upload my work there. If you think my code is ok for *your* project, include it. But couldn't you in addition to the github request also send the patch to the mailing list too? This is what everybody (including you) is doing for the last 5 years and it's working fine. With this move I think you are actively trying to create problems in the established process of patch submission. I understand that you do want you want with your time, but if you don't send the patches to the wmaker-dev mailing list unfortunately they won't be included in the official repository. I hope you change your mind, you've made a lot of contributions already. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Github repository
On 17/11/2013 15:53, Carlos R. Mafra wrote: On Sun, 17 Nov 2013 at 14:34:06 +0100, Rodolfo García Peñas (kix) wrote: On 17/11/2013 13:44, Carlos R. Mafra wrote: On Sun, 17 Nov 2013 at 11:45:23 +0100, Rodolfo García Peñas (kix) wrote: On 17/11/2013 9:37, Carlos R. Mafra wrote: On Sat, 16 Nov 2013 at 23:39:18 +0100, Rodolfo García Peñas wrote: On Thu, 14 Nov 2013, Carlos R. Mafra escribió: I created a wmaker repository in github, https://github.com/crmafra/wmaker I will keep both the old repo.or.cz and the new github updated. Thanks, I am testing it. I sent some patches. Please send the patches to the mailing list. But, If I sent the patches to the mail list, nothing changes. What do you mean by nothing changes? Nothing. My english is too bad, but you cannot understand the difference between you and we. Your project, our project. Again, wmaker is not my project. I guess my agreed-upon status is the maintainer of wmaker, just like you are the maintainer of the wmaker package in the Debian repository. Is the wmaker debian package _your_ project? Or do you consider yourself doing a service to others by being the maintainer of that code in the best possible way as to please the majority of Debian users? The maintainer status is not for life though. If people feel that I'm not capable for maintaining wmaker (for whatever reason) then we can start to discuss who the next maintainer should be and I get out. https://github.com/thekix/wmaker I will upload my work there. If you think my code is ok for *your* project, include it. But couldn't you in addition to the github request also send the patch to the mailing list too? This is what everybody (including you) is doing for the last 5 years and it's working fine. With this move I think you are actively trying to create problems in the established process of patch submission. No. Sorry, but no. If you create a github repo and send a mail to the list pointing it (http://lists.windowmaker.org/dev/msg05993.html): -- 8 -- I created a wmaker repository in github, https://github.com/crmafra/wmaker I will keep both the old repo.or.cz and the new github updated. -- 8 -- I thought that I can send the patches in the github repo. I don't want disturb you. I understand that you do want you want with your time, but if you don't send the patches to the wmaker-dev mailing list unfortunately they won't be included in the official repository. If more people are interested in github, probably they request this method. I hope you change your mind, you've made a lot of contributions already. I hope you change your mind too. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On 10/11/2013 23:32, Carlos R. Mafra wrote: On Sat, 9 Nov 2013 at 23:43:35 +0100, Rodolfo García Peñas (kix) wrote: Carlos R. Mafra crma...@gmail.com escribió: On Sat, 9 Nov 2013 at 21:55:16 +, Rodolfo García Peñas (kix) wrote: Carlos R. Mafra crma...@gmail.com escribió: On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) wrote: The question is: Could you accept a patch in the git that you don't agree with? Yes. Thanks, and about this question: - You're talking about forcing him to discard his aesthetic? - The question is, is their project or is our project? - If wmaker is their project, he can do everyting. If is our - project, perhaps he should hear us. Please, choose, is our or yours? http://en.wikipedia.org/wiki/False_dilemma Why? Should I split the questions? Is yours or our? You are trying to create an artificial separation where there is none. Why do you want to exclude me from your our? That is not true. I don't want to exclude you from the our. This is not a personal attack to you. As I said, you are doing a good work with window maker. Is very difficult for me explain some things in english. So, what is the problem? For me wmaker is a hobbie. I spent a lot of time writting patches, thinking about new ideas. Sometimes I make mistakes and you request me some changes in my patches, and that is perfect. But, IMO, you cannot drop a patch only because you don't agree with. I am not working for you, I am working for the wmaker project, for the users. If you say what is accepted or not, without ask more people, developers; If only you take the decission about what is included or not, then wmaker is your project, and I won't contribute on it. Finally, what do you think about add more commiters to wmaker and dockapps repo? A bad idea. Why? I believe there must be only one person with the final word, otherwise discussions and disagreements will generate tensions and they will have to be resolved by political means. That is your point of view. If I sent patches and you drop them, it will create tensions between us. If you think that a patch shouldn't be included, you ask about it to the developers, and they say that the patch is ok, you should include it, but if the developers say no, I can understand that I did a wrong patch. I try to listen to other people and I change my mind too. For example, my first reaction to the WINGs theming patch was that we don't need this. Yes. After some mails. And about this? http://www.mail-archive.com/wmaker-dev@lists.windowmaker.org/msg03294.html Why it should be a configure option or a DEBUG option? (I don't want the reply). Other developer said that the patch is ok, and for me. But your decission had more weight. But the patch makes the code a bit cleaner too, other people seemed to like the idea and there is no impact in the code. I still think it's not useful to change the look of the widgets, but I'm going to accept the patch nevertheless. See? That should have answered your question about whether I accept things that I don't agree or rather, that I don't like. But nothing seem to matter to you anymore, you already proposed to fork because you find unacceptable to have only one commiter (I wonder what you think about the linux kernel and its single commiter). The problem is not that we have only one commiter. I don't want to be a commiter, is a terrible work. The problem is that only you, take the decissions about what can be uploaded or not. IMO: - Developers - write patches and give the opinion about patches. - Commiter - upload the patches that the developers accepts. IMO, in a democratic idea, the commiter only upload patches. The decission is done by the developers. Of course, the commiter probably is a developer and can give the oppinion, but is only one developer more. See this image about code review (gerrit) http://aniszczyk.org/wp-content/uploads/2011/08/gerrit.png The people can vote the patches. Let me ask you. From the past couple of years of development what would _you_ have done differently? How many patches of disagreement are motivating you to create a fork? I don't want to create a fork, but I cannot accept that only you take the decissions about my work. I can accept that my patches won't be uploaded if the developer team say no, but not only you, because is my hobbie time. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
SJS strem...@stremler.net escribió: Thanks for your comments, [chop] It is just me being conservative and trying to tell people what I think comes close to the edge of acceptance. Who set the edge? Can more people change the edge? The edge is based on the aesthetic sensibilities of the curator; better arguments are the way to change the edge, not the tyranny of the majority. But, if the arguments of the majority are dropped, could we talk about the tyranny of the curator? If you're not going to have a small team handle the duties and argue among themselves, then you've got to rely on a single curator. Perhaps the small team is not invited to handle the duties. You can always fork the repo and run it yourself in parallel. That's the ultimate open-source solution to I'm unhappy with the curation of $project. Yes, but this is the argument of the children that has the game and set the rules. My game, my rules. There are a lot of project and forks for this reason. Many applications to do the same. Is bad be a little bit open? [snip] And in this particular case you mention I said the patch would be accepted if it was not compiled by default. I know what you said. But, why (only) you can say what is accepted or not? Could you accept a patch in the git that you don't agree with? You're talking about forcing him to discard his aesthetic? The question is, is their project or is our project? If wmaker is their project, he can do everyting. If is our project, perhaps he should hear us. Please, choose, is our or yours? That is important for me. And the previous question was not replied, could you accept that patch? kix -- SJS -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Carlos R. Mafra crma...@gmail.com escribió: On Sat, 9 Nov 2013 at 17:13:17 +, Rodolfo García Peñas (kix) wrote: And the previous question was not replied, could you accept that patch? Yes, the patch will be accepted. But he is currently working in a new version of it to address some comments. I don't understand why the rush here. Because I was talking about this question, not about the patch: - And in this particular case you mention I said the patch would be - accepted if it was not compiled by default. - I know what you said. But, why (only) you can say what is accepted or - not? Could you accept a patch in the git that you don't agree with? The question is: Could you accept a patch in the git that you don't agree with? Of course, with the patch with rigth comments, code style,... Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Yaroslav Fedevych jaroslaw.fedew...@gmail.com escribió: On Nov 9, 2013, at 6:24 PM, Carlos R. Mafra crma...@gmail.com wrote: On Sat, 9 Nov 2013 at 17:13:17 +, Rodolfo García Peñas (kix) wrote: And the previous question was not replied, could you accept that patch? Yes, the patch will be accepted. But he is currently working in a new version of it to address some comments. I don't understand why the rush here. People just are being worried and afraid. :-) No. The people is making questions and the questions are not answered. Staying true to NeXTStep foundations, some worry, is a sure way to make WM nothing more than a museum exhibit — something we all better avoid, because WM (fortunately!) is a real piece of software used by real people for real work. I personally hope I won’t need to compare WindowMaker to Lenin’s body in its tomb for the next 40 years or so. So when there is a prolonged silence in response to a patch, or an idea, rumours start circulating, it’s kinda inevitable. Humans being humans. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Carlos R. Mafra crma...@gmail.com escribió: On Sat, 9 Nov 2013 at 19:19:21 +, Rodolfo García Peñas (kix) wrote: The question is: Could you accept a patch in the git that you don't agree with? Yes. Thanks, and about this question: - You're talking about forcing him to discard his aesthetic? - The question is, is their project or is our project? - If wmaker is their project, he can do everyting. If is our - project, perhaps he should hear us. Please, choose, is our or yours? Finally, what do you think about add more commiters to wmaker and dockapps repo? kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
Hi, You are doing a very good job with window maker. Testing patches, trying new things and of course, the git management. Is a hard work and you are always ready to do it. I only can say, thanks a lot. However, I cannot understand your logic about don't include some patches and the way to do it. Yesterday, some developers said that they agree with the patches about WINGs theming, but you didn't include the patches. You didn't explain why, you have your own idea about it (not include them) and for you the topic is closed. We have other similar cases, like for example patches about window maker replaces other window managers and others replace window maker [1]. I feel uncomfortable with these situations. I think more people could upload changes to the git, the git upload could be done using votes, more people review the patches,... be more open. I don't want start a war. I don't want create a wmaker forks here and there and I cannot offer anything. But I like the democratic projects. Regards, kix. [1] http://lists.windowmaker.org/dev/msg05199.html -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Basic WINGs theming
On 05/11/2013 21:57, Carlos R. Mafra wrote: On Tue, 5 Nov 2013 at 20:41:40 +0100, Rodolfo García Peñas (kix) wrote: Hi, You are doing a very good job with window maker. Testing patches, trying new things and of course, the git management. Is a hard work and you are always ready to do it. I only can say, thanks a lot. However, I cannot understand your logic about don't include some patches and the way to do it. Yesterday, some developers said that they agree with the patches about WINGs theming, but you didn't include the patches. You didn't explain why, you have your own idea about it (not include them) and for you the topic is closed. It's been only a day or two since the patch and I'm still thinking and hoping to read more convincing arguments. It would help if the patch included an entry in the NEWS file to teach people about it (including the color syntax). Otherwise I think only a handful of people will be aware of it (nevermind use it). Some patches were accepted and the NEWS file was updated later. I don't like the patch because it smells like let's do it simply because I don't like - 1 person. I like - 3 people. Outcome: The patch is not accepted (yet, sorry) we can, because it is cool to be able to change how the widgets look after all these years. I understand the reasons why someone thinks it is cool, but that is not a strong argument to include features (just think about what would happen otherwise). It is just me being conservative and trying to tell people what I think comes close to the edge of acceptance. Who set the edge? Can more people change the edge? We have other similar cases, like for example patches about window maker replaces other window managers and others replace window maker [1]. I feel uncomfortable with these situations. This is not too fair because it is biased, only the non-accepted patches are remembered and quoted. No, as I said, you made/make a lot of good work. I am talking about the decisionmaking. I don't like some patches were included, for example, because they don't have a right code style, but the patches were accepted. Yes, usually, you are the only person that checks the patches. And in this particular case you mention I said the patch would be accepted if it was not compiled by default. I know what you said. But, why (only) you can say what is accepted or not? Could you accept a patch in the git that you don't agree with? http://lists.windowmaker.org/dev/msg05335.html OTOH DEBUG option? IMO is not a debug option, is a feature. I try to be reasonable in my decisions, but I prefer to err on the conservative rather than the accept all patches side. Yes, but there are more people in the mail list. Probably they can help with the decisionmaking. I think more people could upload changes to the git, the git upload could be done using votes, more people review the patches,... be more open. I said this idea more times. But I had the same result. I don't want start a war. I don't want create a wmaker forks here and there and I cannot offer anything. But I like the democratic projects. Regards, kix. [1] http://lists.windowmaker.org/dev/msg05199.html -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Fwd: WindowMaker: lost maximized status
Hi, some help with this bug? Thanks a lot, Best regards, kix - Mensaje reenviado de Sergey Popov psvor...@gmail.com - Fecha: Thu, 24 Oct 2013 08:56:28 +0200 De: Sergey Popov psvor...@gmail.com Asunto: Re: WindowMaker: lost maximized status Para: Rodolfo kix Garcia k...@kix.es Hi, The problem still exists in 0.95.5. To reproduce: - start gvim gvim --servername qwe .gvimrc - maximize (vertical, horizontal or full) created Gvim window. Window menu has Unmaximize item. - open another (or same) file to the same Gvim window gvim --servername qwe --remote-silent .gvimrc - now winsow menu has Maximize - Gvim window cannot be unmaximized -- maximized status is lost. 2012/5/6 Sergey Popov psvor...@gmail.com Hi, The patch does not solve the problem. Regards, Sergey 2012/5/6 Rodolfo kix Garcia k...@kix.es El 22/04/2012 14:10, Sergey Popov escribió: Hi, Additional info: if maximized window is shaded, the problem does not occur. It seems, the problem in client.c (version 0.95.2) line 221-263: old_geometry is updated to maximized values. Sergey 2012/3/9 Sergey Popov psvor...@gmail.com mailto:psvor...@gmail.com Hi, Correct scenario. If UnMaximize restores normal window size? I open gvim (e.g., 600x400 pixels) - maximize it vertically (now 600x1024) - run second command (remote-silent) - try unmaximize gvim --- it seems, the state is changed from maximized to normal, but window size stays 600x1024 (like maximized vertically). For maximizing I use keybinding, defined in WPrefs. Regards, Sergey 2012/3/8 Rodolfo kix Garcia k...@kix.es mailto:k...@kix.es 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 mailto: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/ Hi, did you see the patch sent some days ago to the mail list? Topic was Patch: Make maximize hotkeys more intuitive. This patch can solve the problem? kix. - Terminar mensaje reenviado - Rodolfo García Peñas (kix) http://www.kix.es/ ---BeginMessage--- Hi, The problem still exists in 0.95.5. To reproduce: - start gvim gvim --servername qwe .gvimrc - maximize (vertical
Re: WindowMaker: lost maximized status
Iain Patterson w...@iain.cx escribió: Here's the patch. I've done some initial testing and nothing seems to have broken but it's probably worth keeping a close eye on things. Yeah! this is fast. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Autostart executing twice
Forwarding to devel list. Cheers, kix. Michael Hellwig e...@fnanp.in-ulm.de escribió: Hello everyone, long-time user of windowmaker here. Since the latest update of the windowmaker package in ARCH, I am seeing an issue where the Autostart file will be executed twice. I only start one program in there but it's one that isn't happy about running twice. Googling for this problem I only found something from way back in 2010 or thereabouts where this was caused by some xrandr extension IIRC? But this seems to be a new problem. What can I do to debug this? Note that I've also had at least one dockapp (i.e. not started from the autostart file but simply launched via the session management) that was started twice upon starting windowmaker, i.e. the app in the dock would launch and a second later the app would also appear in an unlocked instance at the bottom of my screen. I've stopped using this app for other reasons but it seems as if the starting twice problem is not limited to the Autostart file. -- To unsubscribe, send mail to wmaker-user-unsubscr...@lists.windowmaker.info. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH 00/38] Help needed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was thinking about this... Probably is better that more people try to solve the XRandR problem. New ideas, new points of view. Perhaps we should think about create the object, and then add the screens to it. If we plug a new monitor, we add a new screen to the objects, if we unplug the monitor, we remove the screen. I don't know. I will stop here some days. Ideas are welcome. Cheers, kix - -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSY9ZUAAoJEHsfVJByt0kj6TQP/0vD3C4D0V/iZG5YdJfrhwb7 Q4Bx1LKey1EGV0RmR9puO1OF9dXuIVSZXLDw2lkv/1a9YrLmX4uixijDCZxdGcYs dSYfVdnGbtToVYod9DLE2XrHveEyqJwc9mxe54mAVWHCfxsESCQRML541AK012uT KCNIGUn6AWlQQPIDvRjis2x0MkL2dhAuJoUXNTPwEExEe92tpOtmXH9MBk0XCK4I CZ0jgKQt6c7YgvJweWn1/oj7SKbOU7Zsa9Vm89YSeJcLLapRT15BPLj7T4d82fOZ s28Pzav3QVS5DMg1oMEIFMy1QwPIe9nFWmcfEKDC1O+lz4i/XVX+8nL/LjYnODiR x0NDT6Pm9hiqtEVXQpuyh+4Gjy2cZF6YUXSE5/Q4U5z/lEFzA8DIRVYjuvWUkpLa zfagrhP8tRNJe7jfA3uly4UtQh6W0fzi0l5+bMBoumqnhLE66USMoHnTt78g7iW7 6kO9kYT/ikL0jaPGrWsDDcYUEU+hrIa19e8jqbTOuMPv9B0cIndg/d0hSlcDCHrA /cdPJJ6g8Wkt5LYjDRxmy1MXK3pTu2w5/MxwQP8UXuMwJM/RbunQ29x56tW0oqBh ionfy8ptmTbWzizVMWIZl4alq1NjONIZowTCkbJlHd0Jqgq7krly71iPlQPu/H+H jZb1Ub4LsfqRaovZ/DBA =xxsJ -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/6] A few bug fixes and one minor improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/10/2013 22:36, Daniel Déchelotte wrote: On Sat, 19 Oct 2013 Rodolfo García Peñas k...@kix.es wrote: - Push and hold Alt key - Click on the docked app - Detach it from the Clip (continue holding the Alt key and the mouse button) Now, if you try to attach it again, you can't! You must release the Alt key and then push it again to attach the icon again (don't release the mouse button). With the old behavior, when you hold the Alt key and detach the icon, then, the shadow is painted and the icon is ready to be attached to the Clip or the Dock. Alright, so we are talking of the same thing, but disagreeing on what factually happened in the old behavior :). I maintain that, in the old Nice :-) If the mouse button is released while Alt is pressed (and after the mouse is moved a bit :-/), you are in step 3 above: no docking. If Alt is no longer pressed, step 5, docking is possible. This is what I observed in wmaker-0.95.1 (Jan 2013). Do you repro the I can move an appicon from a dock to another with Alt pressed behavior with that version? Ok, forget all. What should be the rigth behavior? 1. Alt button always pressed detatch and attach the icon? 2. Alt button pressed detach the icon + released attach it again? I don't know if the wmaker-0.95.1 (Jan 2013) version was option 1 or option 2. I think the original behavior was option 1, but I am not sure now. But... what we want now? Thanks Daniel! kix -- Daniel - -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSY9haAAoJEHsfVJByt0kjhjkP/1Zf8vyE6TqYL5kw1X0EzDwy HIOvrVX8rW6LnMWXDUc0RLwaT+w5Lyfzocgmdxq0/i5Zz4Z+lWh3ZdSqL0AFkdcI 3LiFO/ya7y/fGc8AMS7Q8Juay3Pzx5fOs0LxrFeK9lBB7zhr+HVEis1LIiGHhkb+ E3Fz2L2Rg59B79B43zHOmJ4Ipk59BIFeaNtAfQ72Qp4tV1cg5awKyougbaQHxb5j ePCivi+IVQEk7vHmEOBAfccWb999KJEqNCP/h5B42OPP+OULToo1SBViRTjlRz+o NtWlEC1JAipeZ28yH0BgPtJxeQCrQK62FEKeFRbBPUfyn6nLMBXqQ65YYX11Iaru Bv7+l3DJoJfLoYXz+MsmKvwYduhQFD32Y0gk+7tn2SGdXlIqhw7D4lVlktYlozhr cmk1j15r5b7eAv4Hx29Dxw+wSi1h+FsGP5dhuG7viaOwtMulygBAVEQ3x1Y8P/Ty q1bq8cMBn3ZoEdaOh5THBRe+CcMPTcdxavUeNvEEZli4JD78yohECZeTBkDiNqfD g4rFQM+WCQmR0Ux4ZjqTda3st32RjBFBpIaj2/q/xhAg2ZpYp3/8f2m2PSLVSX62 R5ZcbHB1eUraqqtbf2Pj2OBsYnOQ2/gwP3JkYxWzfWSkhVwTOqDjXGp3+CFIftR4 dgIRrBuLZROLLKGKNM7K =YAuq -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Wrong behavior
Hi, if we have a dock, and multiple desktops, If I hold the Alt key and then make double click on a docked icon, wmaker switch the workspace to N-1. If I hold the Alt key and then make double click in a running dockapp (wmclock,...), wmaker changes the workspace to 1 :-/ This is ok? Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/6] A few bug fixes and one minor improvement
Hi Daniel, the behavior is not the same than before. If we have the clip and the dock, and I move the icon without Alt key, using the icon border, I can move the icon from the clip to the dock, with the shadow,... But, If I move the icon using the Alt key, I can press on the icon, detach from the Dock/Clip but when I move the icon near the Dock/Clip, the icon cannot be attached and the shadow is not painted. I need to release the Alt key, and push it again. Is possible to do it without release the alt key? Thanks kix. yo@free.fr escribió: From: Daniel Déchelotte yo@free.fr The first patch fixes the bug recently discussed in the thread IMPORTANT BUG: Unable to attach dockapps to Clip/Dock. Then 3 fixes, one for a crashing bug. Then a minor improvement when removing a drawer with a single appicon, and removing some dead code. Daniel Déchelotte (6): When moving an undocked appicon (or applet), allow it to be docked even if Alt is still pressed BF: prevents crash when toggling auto-attract on a drawer with clip disabled BF: correctly initialize the drawer tile when the dock is on the left side BF for stacking level bug when creating a drawer in a keep-on-top dock When removing a drawer containing a single appicon, the latter is docked where the drawer was, instead of being totally undocked. Remove dead code for a confirmation dialog that we'll probably never want to show src/appicon.c |2 +- src/dock.c| 68 + src/screen.c | 11 +- 3 files changed, 41 insertions(+), 40 deletions(-) -- 1.7.10.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: annoying multi-screen issue
Paul Harris harris...@gmail.com escribió: Hi guys, I have trouble with multiple monitors, to ensure I don't get stuck without any screens, I use nvidia-settings to change my resolution. But, Windowmaker doesn't notice the change in screen layout. Instead, it seems I have to always use the menu to restart wmaker. Is this something that could be fixed in the future? Yes. There's a solution for everything but death (and I am trying a patch ;-) ). Cheers, kix cheers, Paul Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Clips and Dock
Hi Daniel, thanks a lot for your comments. I will review my local repo and will change some things. Cheers, kix Daniel Déchelotte yo@free.fr escribió: Hi kix, When you have two monitors, you basically have two options. The most popular one nowadays is to merge the two screens into a wide one with xrandr (earlier it was with Xinerama, or TwinView, or BigDesktop, or whatnot). Then you really have one screen (in X.org sense), which is quite possibly not rectangular. WM manages that single screen and displays a single dock, at the left of the leftmost head (monitor) or at the right of the rightmost one. The other option is to keep the two screens separate. As I understand, windows can't extend from one screen to another, they can't be moved across screens. There is a single X server, the user logs in once and he gets two screens, but those are totally independent from each other. A single instance of WM manages both, and each has its own dock. I've never run that setup; in fact, I wouldn't even know how to force X to keep the two screens separate to test my changes in that condition. But I think that explains the multiple screen code in WM. HTH, -- Daniel PS: the excerpt below is from startup.c ;-) - Mail original - Hi, only one stu^H^H^H simple question. There are one Clip per Workspace, but... How many Docks are in wmaker? One? Is the same for all workspaces? Probably seems an s^H simple question, but I am working on workspaces these days and yesterday I had this question. See this: screen.c: 722 if (!wPreferences.flags.nodock wScreen[j]-dock) 723 wScreen[j]-last_dock = wScreen[j]-dock; This code show that there are one Dock per Screen. IMO, it makes no sense. I have code here with only one Dock. I am testing. Cheers. kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Replace and be replaced
Yaroslav Fedevych jaroslaw.fedew...@gmail.com escribió: On 29 sie 2013, at 11:37, Carlos R. Mafra crma...@gmail.com wrote: On Thu, 29 Aug 2013 at 10:32:40 +0100, Iain Patterson wrote: Quoth I, This patch allows wmaker to replace existing window managers with the --replace flag, like xfwm4 and metacity can. It also allows those window managers (or another wmaker) to replace wmaker in the same way. Any interest in this kind of stuff? I don't know if wmaker needs that stuff. I feel it's too much code for a possible minimal gain and I'd prefer to keep things simple. But at least it would be on par with almost every other window manager under the sun. Think interoperability, compatibility... I think like Carlos about wmaker should be simple. But in this case, IMO the window managers should do a minimum amount of things to be standard, like probably this. If other window managers can replace others, and is a common feature, probably we should implement it... and is already done, so use it. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Alt+tab crashes Windowmaker
Juan Giordana juangiord...@gmail.com escribió: Hello, I'm using Linux mint and just built the latest Windowmaker from the git repo and it crashed when I tried to switch windows with alt+tab. - I've created 5 workspaces and added some keyboard shortcuts to my config and selected the optoin to raise the windows while switching them with alt+tab - Went to the workspace 'www' opened chromium, opera, firefox and an xterm - Quickly pressing Alt+tab crashed WindowMaker - Not so quickly behaves poorly. Regards Hi Juan, could you help us with git bisect to find the wrong git commit? Thanks, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : Re: Re : Re: [PATCH 06/19] wmaker: Reorganised the header 'funcs.h'
Hi I Am not with my laptop, short answer. I don't agree because your proposal is include all headers files in all source files. We should include only the headers needed. Cheers Kix Quoting Christophe christophe.cu...@free.fr: - Carlos R. Mafra crma...@gmail.com a écrit : On Sun, 12 May 2013 at 13:13:45 +0200, Christophe wrote: [...] I tend to prefer having separate header files matching their .c files. It is simpler conceptually. Sorry for the late answer, have been quite busy again... Maybe it's a bit late now, as Rodolfo has started the clean-up, but I was thinking about a methodology which could be added to the coding style rules: - All source files must include only 1 header * that does not count system headers * the idea is to avoid missing some #include, like it was the case before * this header handles in one place the inter-dependency of headers - All source file must define their own header, from the moment they share more than 3 functions or a struct definition * the arbitrary limit of 3 is here to avoid too small file which scatter things * uses 'WM_filename_in_uppercase_H' for include guards * defines structs first, then function prototypes (with a comment separator between the 2 sections) - The common header does this, in *this* order: * includes config.h from configure * includes system headers that may be needed (types used in headers and covers the HAVE_xxx from configure detection) * defines anonymous structs that are needed (typedef struct name name; without content) * includes all the source headers (handles the right order, makes sure nothing is missing) * defines the prototypes for functions in the case of 3-or-less functions from above (with appropriate separator comment with source file name) This is, of course, open to comments, but it provides a good base to have things in a safe, easy-to-work-with state. Regards, Christophe. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Cube dock image
Hi, I did it using a snapshot and gimp. Test it please. Cheers, kix. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ attachment: dockcube.tiff dockcube.xcf Description: Binary data
Re: Add dock icon to wmaker
On 11/05/2013 22:00, BALATON Zoltan wrote: On Sat, 11 May 2013, Rodolfo García Peñas (kix) wrote: is possible add that [1] icon to wmaker? I am thinking add the icon to the available icons in wmaker. Using it as default dock icon is other story. [1] http://lists.windowmaker.org/dev/msg04515.html I don't have that icon either that's why I was asking the same question but I never got an answer. Regards, BALATON Zoltan I sent a tweet to @crunchbang, because is a distro... and perhaps they included that file. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Add dock icon to wmaker
Hi, is possible add that [1] icon to wmaker? I am thinking add the icon to the available icons in wmaker. Using it as default dock icon is other story. [1] http://lists.windowmaker.org/dev/msg04515.html Cheers, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 06/19] wmaker: Reorganised the header 'funcs.h'
On 12/05/2013 0:24, Christophe wrote: From: Christophe CURIS christophe.cu...@free.fr The functions are now grouped by source file (groups in alphabetic order) with the traditional separation mark. This makes the file easier to work with. --- src/funcs.h | 53 ++--- 1 file changed, 38 insertions(+), 15 deletions(-) Hi Christophe, thanks a lot for your patches. Hard work. Only one comment about this patch. The file funcs.h contains prototypes for multiple files, and funcs.c doesn't exist. IMO, is better move the prototypes to the right header file, and remove funcs.h. Probably we can apply this idea for src/keybind.h Other options (fuzzy): - Files like extend_pixmaps.h and def_pixmaps.h could be merged. - GNUstep.h and WindowMaker.h probably could be checked,... Again, thanks for your work. kix. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/3] Screen initialization doesn't create workspace
On 20/04/2013 16:14, Rodolfo García Peñas (kix) wrote: From: Rodolfo García Peñas (kix) k...@kix.es When the screen is created, it creates the initial workspace. This workspace could not be created, because is not used. The workspaces are created later, so we can F*ck!!%4$1~ forget this serie, I forgot 1 patch (the first) -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 4/8] Split dock menu creation
Hi Carlos,
something is wrong in this patch. Please, don't apply it yet.
Sorry.
kix
Quoting Rodolfo García Peñas (kix) k...@kix.es:
From: Rodolfo García Peñas (kix) k...@kix.es
The function dockMenuCreate is splitted in four functions:
- create_clip_main_menu(WScreen*)
- create_dock_main_menu(WScreen*)
- create_drawer_main_menu(WScreen*)
- dockMenuCreate(WScreen*, int*)
The function create_clip_main_menu() creates the menu and the menu items
when the menu is for a Clip.
The function create_dock_main_menu() creates the menu and the menu items
when the menu is for a Dock.
The function create_drawer_main_menu() creates the menu and the menu items
when the menu is for a Drawer.
The function dockMenuCreate() is now smaller, and more clear. The function
select if the menu creation is for a clip, drawer or dock, and then call the
right function. The function uses switch-case instead if-else and controls
if the Clip or Drawer were previously created. The menu and menuitem creation
is outside then, is easier to understand it.
This patch introduces a code duplication for some items, but removes some
checks about is Clip?, is Drawer,... This code duplication is better
because the menuitem position could be differente for Clip, Dock or Drawer.
---
src/dock.c | 194
+---
1 file changed, 134 insertions(+), 60 deletions(-)
diff --git a/src/dock.c b/src/dock.c
index 7f277c5..2801617 100644
--- a/src/dock.c
+++ b/src/dock.c
@@ -1184,79 +1184,130 @@ static WMenu *makeDockPositionMenu(WScreen *scr)
return menu;
}
-
-static WMenu *dockMenuCreate(WScreen *scr, int type)
+static WMenu *create_dock_main_menu(WScreen *scr)
{
WMenu *menu;
WMenuEntry *entry;
- if (type == WM_CLIP scr-clip_menu)
- return scr-clip_menu;
+ menu = wMenuCreate(scr, NULL, False);
+ entry = wMenuAddCallback(menu, _(Dock position), NULL, NULL);
+ if (scr-dock_pos_menu == NULL)
+ scr-dock_pos_menu = makeDockPositionMenu(scr);
+ wMenuEntrySetCascade(menu, entry, scr-dock_pos_menu);
+
+ if (!wPreferences.flags.nodrawer)
+ entry = wMenuAddCallback(menu, _(Add a drawer),
addADrawerCallback, NULL);
+
+ wMenuAddCallback(menu, _(Launch), launchCallback, NULL);
+ wMenuAddCallback(menu, _(Unhide Here), unhideHereCallback, NULL);
+
+ entry = wMenuAddCallback(menu, _(Hide), hideCallback, NULL);
+ wfree(entry-text);
+ entry-text = _(Hide); /* can be: Unhide */
- if (type == WM_DRAWER scr-drawer_menu)
- return scr-drawer_menu;
+ wMenuAddCallback(menu, _(Settings...), settingsCallback, NULL);
+
+ entry = wMenuAddCallback(menu, _(Kill), killCallback, NULL);
+ wfree(entry-text);
+ entry-text = _(Kill); /* can be: Remove drawer */
+
+ return menu;
+}
+
+static WMenu *create_clip_main_menu(WScreen *scr)
+{
+ WMenu *menu;
+ WMenuEntry *entry;
menu = wMenuCreate(scr, NULL, False);
- if (type == WM_DOCK) {
- entry = wMenuAddCallback(menu, _(Dock position), NULL, NULL);
- if (scr-dock_pos_menu == NULL)
- scr-dock_pos_menu = makeDockPositionMenu(scr);
- wMenuEntrySetCascade(menu, entry, scr-dock_pos_menu);
+ entry = wMenuAddCallback(menu, _(Clip Options), NULL, NULL);
- if (!wPreferences.flags.nodrawer) {
- entry = wMenuAddCallback(menu, _(Add a drawer),
addADrawerCallback, NULL);
- }
- } else {
- if (type == WM_CLIP)
- entry = wMenuAddCallback(menu, _(Clip Options), NULL,
NULL);
- else /* if (type == WM_DRAWER) */
- entry = wMenuAddCallback(menu, _(Drawer options),
NULL, NULL);
-
- if (scr-clip_options == NULL)
- scr-clip_options = makeClipOptionsMenu(scr);
- wMenuEntrySetCascade(menu, entry, scr-clip_options);
-
-/* The same menu is used for the dock and its appicons. If the
menu
- * entry text is different between the two contexts, or if it
can
- * change depending on some state, free the duplicated string
(from
- * wMenuInsertCallback) and use gettext's string */
- if (type == WM_CLIP) {
- entry = wMenuAddCallback(menu, _(Rename Workspace),
renameCallback, NULL);
- wfree(entry-text);
- entry-text = _(Rename Workspace); /* can be:
(Toggle) Omnipresent */
- }
+ if (scr-clip_options == NULL)
+ scr-clip_options = makeClipOptionsMenu(scr);
- entry = wMenuAddCallback(menu, _(Selected), selectCallback,
NULL);
- entry-flags.indicator = 1;
- entry-flags.indicator_on = 1;
- entry-flags.indicator_type = MI_CHECK
Re: [PATCH 6/8] Create clip only if needed
Quoting Carlos R. Mafra crma...@gmail.com:
On Tue, 16 Apr 2013 at 23:25:10 +0200, Rodolfo García Peñas (kix) wrote:
On 16/04/2013 22:06, Carlos R. Mafra wrote:
+int wWorkspaceNew(WScreen *scr, Bool with_clip)
{
WWorkspace *wspace, **list;
int i;
@@ -102,7 +102,7 @@ int wWorkspaceNew(WScreen *scr)
sprintf(wspace-name, _(Workspace %i),
scr-workspace_count);
}
- if (!wPreferences.flags.noclip)
+ if (!wPreferences.flags.noclip with_clip)
This seems redundant.
Why can't you use the noclip flag directly instead of adding the new
with_clip argument? Ie, if the noclip flag is set then that should be
equivalent to your !with_clip case.
Hi Carlos,
these flags are different.
wPreferences.flag.noclip is used when the user don't want to use the clip.
Then, if the flag is set, the Clip is never used.
So if the user doesn't want the clip you should not create it in the first
place too. So instead of adding an extra parameter to control the creation,
simply use the existing flag to make the decisions. I don't see the need
to add the with_clip argument when you already have a noclip flag.
Brrr, I need improve my english.
This is the current flow:
1. The workspace creates the clip when is restored
2. The clip is removed
3. The Clip is created again if the flag noclip is not set.
With the patch, the flow is:
1. The workspace is created, but not the clip, when is restored - The
with_clip flag is used for that
2. The clip is not removed, because is not created in the step 1
3. The Clip is created if the flag noclip is not set. - We use the
noclip flag for that
Then, only the step 3 creates the Clip.
If the flag noclip is set, without the patch, then, the Clip is never
created in the step 3 (I am not sure if is created in the step 1, I
need check the code).
If we use the flag noclip with the funcionality of with_clip flag, the
flow should be:
1. Set the noclip flag to false
2. The workspace is created, but not the clip, when is restored
(again, I need check if this function test the noclip flag)
3. The clip is not removed, because is not created in the step 1
4. *Restore* the initial value of noclip, because the user might see
the clip
5. The Clip is created if the flag noclip is not set.
When we set the with_clip flag is only for that function flow, but not
for all the wmaker session.
I don't see why these things have to be different. If noclip is set in
WPrefs the user already told wmaker he doesn't want a clip, so the
functions should not create it.
And if the user want the clip? He select the noclip to false, then
the clip is created when the workspace is restored, then removed, then
created again...
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Move the Add drawer option down
IMO, the option Add drawer should be moved down in the dock's menu. IMO, the right list sort should be: - Launch - Bring here - Hide - Settings - Dock position - Add drawer - Kill I use sometimes the Launch option and now I am adding drawers every time. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 4/8] Split dock menu creation
Quoting Carlos R. Mafra crma...@gmail.com: On Wed, 17 Apr 2013 at 6:37:57 +, Rodolfo García Peñas (kix) wrote: Hi Carlos, something is wrong in this patch. Please, don't apply it yet. I was not planning to apply it. I don't think that all that code movement is worth the trouble. We will need some parts of this code to the XRandR too. The XRandR needs split the item creation and the item painting. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/8] Add the application to the wapp_list
Quoting Carlos R. Mafra crma...@gmail.com:
On Sun, 14 Apr 2013 at 23:13:28 +0200, Rodolfo García Peñas (kix) wrote:
From: Rodolfo García Peñas (kix) k...@kix.es
The screen has a list of applications:
8
kix@debian:~/src/wmaker/wmaker-crm/src$ grep wapp_list screen.h
struct WApplication *wapp_list;/* list of all aplications */
kix@debian:~/src/wmaker/wmaker-crm/src$
8
But this variable was not set before this patch:
- Was removed in application.c
- Local variable in session.c
8
kix@debian:~/src/wmaker/wmaker-crm/src$ grep wapp_list *.c
application.c: if (wapp == scr-wapp_list) {
application.c: scr-wapp_list = wapp-next;
session.c: WMArray *wapp_list = NULL;
session.c: wapp_list = WMCreateArray(16);
session.c: (WMGetFirstInArray(wapp_list, (void *)appId)
== WANotFound
session.c: WMAddToArray(wapp_list, (void *)appId);
session.c: WMFreeArray(wapp_list);
kix@debian:~/src/wmaker/wmaker-crm/src$
8
This variable is needed to restore the screen without re-create the
applications structs.
---
src/application.c |4
1 file changed, 4 insertions(+)
diff --git a/src/application.c b/src/application.c
index abe1d2d..6a03775 100644
--- a/src/application.c
+++ b/src/application.c
@@ -143,6 +143,10 @@ WApplication *wApplicationCreate(WWindow * wwin)
create_appicon_for_application(wapp, wwin);
+ /* Save the application in the application list */
+ wapp-next = scr-wapp_list;
+ scr-wapp_list = wapp;
If wapp_list was not set before then wapp-next will contain junk
at this point, no?
Yes. Good point. We should initialize the wapp_list when wmaker starts.
This list is needed to re-position the windows, for example with
XRandR screen change.
We have a different list for appicons. See src-app_icon_list. Is the
same idea.
With XRandR, we should follow the app_icon_list to re-position the
appicons and then paint it (move them). And we should follow the
wapp_list to to the same with the windows.
I didn't found where the app_icon_list is initialized.
Cheers,
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 6/8] Create clip only if needed
On 16/04/2013 22:06, Carlos R. Mafra wrote:
+int wWorkspaceNew(WScreen *scr, Bool with_clip)
{
WWorkspace *wspace, **list;
int i;
@@ -102,7 +102,7 @@ int wWorkspaceNew(WScreen *scr)
sprintf(wspace-name, _(Workspace %i),
scr-workspace_count);
}
-if (!wPreferences.flags.noclip)
+if (!wPreferences.flags.noclip with_clip)
This seems redundant.
Why can't you use the noclip flag directly instead of adding the new
with_clip argument? Ie, if the noclip flag is set then that should be
equivalent to your !with_clip case.
Hi Carlos,
these flags are different.
wPreferences.flag.noclip is used when the user don't want to use the clip.
Then, if the flag is set, the Clip is never used.
When we set the with_clip flag is only for that function flow, but not for all
the wmaker session. I use that flag because the workspace, when is created, can
create the clip or not.
Before these patches, the flow is something like:
1. Create a clip - This clip is used to set the src-clip* values.
2. When every workspace is created, the flow is this:
878 clip_state = WMGetFromPLDictionary(wks_state,
dClip);
879 if (scr-workspaces[i]-clip)
880 wDockDestroy(scr-workspaces[i]-clip);
881
882 scr-workspaces[i]-clip = wDockRestoreState(scr,
clip_state, WM_CLIP);
883 if (i 0)
884 wDockHideIcons(scr-workspaces[i]-clip);
First remove the clip, then create it again.
This flag select if the Clip should be created or not. Then, when the workspace
is created, with this patch, the clip is not created, therefore, we don't need
to destroy it later. Then, probably the lines 878-880 could be removed, but I
didn't have enough time to check it.
kix.
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
XRandR things
Hi, the next days I will be busy. I would like to share some ideas to make the XRandR integration easier. When the user adds/removes a screen these items change: 1. Screen size. 2. Workspace size. 3. Dock position. 4. Clip position. 5. Menu position (if open). 6. Appicons position. 7. Window position (for example, if the windows are out of the screen). I think, that is all. The work when the screen changes is easy: We must move the things in the screen, BUT don't create it again. Points 1 and 2 are so easy. I wrote the code. The Dock position is easy too. I can move the Dock without problems (left, or right). I didn't have time for 5,6,7. But, I have some ideas with Clip and now with Drawers. 1. I don't know how to split the drawer creation and the drawer position without create it. Daniel, help is welcome. About that, I don't know why the Drawer is not like the Clip. I sent some questions to Daniel, but no reply :-( What is the meaning of like the Clip? The idea is use the same functions the clip uses, then we don't need a lot of xyzDrawerxyz() functions (RestoreDrawer, HideDrawer,...). 2. I would like to change the Clip behaviour. I think the clip could be in 9 different positions on the screen (something like the appicons): 1. Near the right border 2. Near the left border 3. Near the top of the screen 4. Near the bottom of the screen 5. 1+3 6. 1+4 7. 2+3 8. 2+4 9. Not near the borders. Near could be something like x pixels or a new flag hold near of the border or something like. Then, when the screen size changes, the Clip is moved to the right position. For exaple, in my laptop the clip is in 1024x768 (minus 64 pixels...), that is the bottom right of the screen. When I connect an external monitor (1920x1080), the Clip is in the same position (1024x768). The idea is move the Clip to 1920x1080). We have two options: 1. Add a new preference, check or something in the Clip 2. Try to calculate it by the way. p.e. if (x_pos -5 = old_screen_x_size) then move_clip_x(new_screen_x_size) (and the same for y). If we don't add this behaviour to the clip, with XRandR, the Clip is in the same position after the window change. What do you think? Cheers, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 15/20] Add drawers to wmaker!
On 12/04/2013 1:42, yo@free.fr wrote:
From: Daniel Déchelotte yo@free.fr
Hi Daniel,
first, your patches are impressive. Congrats. I have some comments about
them:
[snip]
switch (which) {
case WM_DOCK:
wPreferences.flags.nodock = wPreferences.flags.nodock || *flag;
+ // Drawers require the dock
+ wPreferences.flags.nodrawer = wPreferences.flags.nodrawer ||
wPreferences.flags.nodock;
break;
First, you are using // for comments, C++ comments... But the main
question is why drawers require the dock?
Reading the main.c file I saw that if you use the dock and clip as one
thing:
} else if (strcmp(argv[i], -nodock) == 0 ||
strcmp(argv[i],
--no-dock) == 0) {
wPreferences.flags.nodock = 1;
+ wPreferences.flags.nodrawer = 1;
Why? If the user set the nodock flag, then cannot use drawers?
IMO that is wrong.
diff --git a/src/main.c b/src/main.c
index f63b1a6..4559f86 100644
--- a/src/main.c
+++ b/src/main.c
@@ -686,8 +686,11 @@ static int real_main(int argc, char **argv)
wPreferences.flags.norestore = 1;
} else if (strcmp(argv[i], -nodock) == 0 ||
strcmp(argv[i], --no-dock) == 0) {
wPreferences.flags.nodock = 1;
+ wPreferences.flags.nodrawer = 1;
} else if (strcmp(argv[i], -noclip) == 0 ||
strcmp(argv[i], --no-clip) == 0) {
wPreferences.flags.noclip = 1;
+ } else if (strcmp(argv[i], -nodrawer) == 0 ||
strcmp(argv[i], --no-drawer) == 0) {
+ wPreferences.flags.nodrawer = 1;
} else if (strcmp(argv[i], -version) == 0 ||
strcmp(argv[i], --version) == 0) {
printf(Window Maker %s\n, VERSION);
exit(0);
diff --git a/src/screen.c b/src/screen.c
index bc8f3fa..8d1c46c 100644
[snip]
+/* Drawers, which are docks, really */
+typedef struct WDrawerChain {
+struct WDock *adrawer;
+struct WDrawerChain *next;
+} WDrawerChain;
Really, IMO the right way is use one internal struct WDock (or any
name), with the full behaviour (clip, dock and drawers), then, select
the type.
About the if brackets... I did a lot of clean patches to use the KR
style (I wrote about that in my previous comments to your patches).
IMO your patches are very very big. Some changes are not related to add
drawers. Probably the patches should be sent with more time between
them. There is no way to understand all (with standard human time)
Only this patch:
19 files changed, 1560 insertions(+), 220 deletions(-)
Your patches might use the last patch in #next.
I will need more time for xrandr patches.
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 15/20] Add drawers to wmaker!
On 12/04/2013 1:42, yo@free.fr wrote: From: Daniel Déchelotte yo@free.fr Just discovered this bug: the auto-attract icon functionality will not work (to be precise, it crashes WM!) if the clip is disabled (NoClip=YES). Will fix shortly, of course. You should release an specific patch for this bug. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 17/20] Real-time dock left-right swapping
On 12/04/2013 1:42, yo@free.fr wrote: From: Daniel Déchelotte yo@free.fr No more ghost dock when switching sides: the real swap happens immediately, you can still adjust vertically afterwards. Removed two functions in superfluous that are no longer used Why? I am not sure we should remove the Dock Ghost. It show to the user that only can set the new position for the dock in that place (right, left). What happends if the user try to put the dock in the top border or in the bottom, like the KDE, GNome,... panels? -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 19/20] Wrap appicons when dock is moved up and down
On 12/04/2013 1:42, yo@free.fr wrote:
From: Daniel Déchelotte yo@free.fr
Add WrapAppiconsInDock option to control that behaviour (default: YES)
---
As I said in my previous comments, this functions are not right:
+static int setWrapAppiconsInDock(WScreen *scr, WDefaultEntry *entry, char
*flag, void *foo)
+{
+ wPreferences.flags.wrap_appicons_in_dock = *flag;
+ return 0;
+}
you are passing arguments that you don't use, you are returning always
the same value, so, the funcion should be void. Then, one function for
only one line?
I am not really confortable with the patches. Yes, the drawers
functionality is incredible, but the IMHO the cost is very high.
Cheers,
kix
--
||// //\\// Rodolfo kix Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : Question about XRandR info dialog
On 09/04/2013 23:29, Christophe wrote: Hi Rodolfo, The idea is interesting, I'd propose to take the opportunity of the patch to make a few changes below (or maybe that should be split in 2 patches): - Rodolfo García Peñas k...@kix.es a écrit : Hi, I am thinking in send this small patch for the info panel: diff --git a/src/dialog.c b/src/dialog.c index 6964495..63c11db 100644 --- a/src/dialog.c +++ b/src/dialog.c @@ -1243,6 +1243,14 @@ void wShowInfoPanel(WScreen * scr) } strbuf = wstrappend(strbuf, _(\nAdditional support for: WMSPEC)); you could take the opportunity to split this in 2: - the string Additional support first, with the _ for translation - the WMSPEC afterward, without translation _ this might make translation strings a bit better + +#ifdef HAVE_XRANDR + if (has_randr) + strbuf = wstrappend(strbuf, XRandR (In use)); + else + strbuf = wstrappend(strbuf, XRandR (Not in use)); similarly, I would suggest to separate the XRandR string which shall not be translated. On a pure personal point of view, I would suggest Active/Inactive instead, but that's just a matter of taste... Supported/Not Supported ? if xrandr is compiled, has_randr checks if the X-Server supports this extension. +#endif + #ifdef MWM_HINTS strbuf = wstrappend(strbuf, and MWM); Would suggest also to take the opportunity to remove the 'and' there for translation job simplification. As a general matter, I would recommend to use a comma for separating the keyword (something like , XXX). #endif What do you think? The text is correct? Thanks, 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.
Help with multiple calls to handleExtensions
Hi, first, I have a new code for XRandR. This code can move the WDock and WClip to the right position, scale the screens and move the appicons. I need move menus and windows yet. Restart windowmaker is not needed now. The code is ugly (yet) and I will re-write the patches before send them. I have one small issue: The problem is the calls to handleExtensions (line 305): 297 case ConfigureNotify: 298 #ifdef HAVE_XRANDR 299 if (event-xconfigure.window == DefaultRootWindow(dpy)) 300 XRRUpdateConfiguration(event); 301 #endif 302 break; 303 304 default: 305 handleExtensions(event); 306 break; 307 } I don't know why handleExtensions() is called multiple times (2 or 4) [yes, because we got multiple default events,...). I saw that when I started to write the code, and I don't care about it, but now, trying to get the final postion for appicons, I have problems because the appicons has holes between them. Any help? Thanks. kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: dockapps.git repo redesign question
On 03/04/2013 18:59, Alexey I. Froloff wrote: On Wed, Apr 03, 2013 at 06:03:09PM +0200, Rodolfo García Peñas (kix) wrote: I think that every dockapp should continue with their version number if the code doesn't change. I think dockapps repo is only to hold all applications together and avoid lost them. How do you suggest tracking dockapp versions? IMO, I should use the version number included in the code by the last person that make changes. If there are changes, but no new version, then using the old version number, +git-date where date is mmdd. perhaps the script used to do the nightly package for wmaker (at debian folder) can help you to create the .tgz files. You can create the .tgz for every dockapp, with a new version, only if the revision change. What is that revision you are talking about? I've changed the code of wmfoo dockapp and decided to release version 0.4.18. What's next? How do I tag this release and make a tarball? I don't know. Perhaps incluiding some file with the revision number. Next question: I want to make tarball for the newest version on wmbar dockapp. Just checked out the dockapps repo. How can I do that? If you are uploading the .tgz to any place, then the package is there. But, anyway. I think your idea is good (except I don't like github). If you (or you and Carlos, or you Carlos and X (where X is not me [sorry, but really, my time^H^H^H^H no time])) maintain the dockapps repo, perfect. I only try to say that every dockapp is different, because are different applications, and have different files and different file tree. Perhaps, we should work in other direction, like change things to make the dockapps with the same struct, include machine-readable files,... I don't know. I wrote in my notebook (paper): - Create an script to make dockapps tgz's and upload to any place. - Create a new dockapp library with the common code to do common (basic) things, like: * Code to read the CPU (used by wmmon, wmcpumon,...) * Code to read the network interfaces (speed,...) used by multiple dockapps too. Because I am not doing it, because I am with other things, feel free to do what you want. If you need help, and I can help you, I'm here. One thing more, please hold only *one* repo for the dockapps. Saludos, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 5/6] New function get_right_position_on_screen
On 03/04/2013 20:33, Carlos R. Mafra wrote:
On Wed, 3 Apr 2013 at 20:01:49 +0200, Rodolfo García Peñas (kix) wrote:
From: Rodolfo García Peñas (kix) k...@kix.es
The function get_right_position_on_screen() sets the right position
in the screen using a WRect.
This description confuses me a bit. The function is named get_ but it sets the
position, so it should be named set_, no?
It moves the x and y coordinates to the right place.
So what's the _right_ in the name? It is 'right' as opposed
to 'left' or is it 'right' as 'correct'?
From my brief reading of the function, I think that dropping
the 'right' from the name would not create confusion, or do
you envision having a set_left_position_on_screen()?
I don't know if I'm making sense, though :-)
Sorry, correct.
This patches checks if the x,y inside the screen, using a rect.
Is something like:
is x is minor, is outside (left)
if x is greater, is outside (rigth)
...
---
src/menu.c | 16 +++-
src/placement.c | 17 +
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/src/menu.c b/src/menu.c
index 696daa0..5a52d36 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -43,6 +43,7 @@
#include workspace.h
#include dialog.h
#include rootmenu.h
+#include placement.h
/** Global Variables **/
@@ -1068,19 +1069,8 @@ void wMenuMapAt(WMenu * menu, int x, int y, int
keyboard)
}
if (!menu-flags.mapped) {
-if (wPreferences.wrap_menus) {
-WScreen *scr = menu-frame-screen_ptr;
-WMRect rect = wGetRectForHead(scr,
wGetHeadForPointerLocation(scr));
-
-if (x rect.pos.x)
-x = rect.pos.x;
-if (y rect.pos.y)
-y = rect.pos.y;
-if (x + MENUW(menu) rect.pos.x + rect.size.width)
-x = rect.pos.x + rect.size.width - MENUW(menu);
-if (y + MENUH(menu) rect.pos.y + rect.size.height)
-y = rect.pos.y + rect.size.height - MENUH(menu);
-}
+if (wPreferences.wrap_menus)
+get_right_position_on_screen(menu-frame-screen_ptr,
x, y, MENUW(menu), MENUH(menu));
XMoveWindow(dpy, menu-frame-core-window, x, y);
menu-frame_x = x;
diff --git a/src/placement.c b/src/placement.c
index 5e4a8e7..5a3eaa9 100644
--- a/src/placement.c
+++ b/src/placement.c
@@ -565,3 +565,20 @@ void PlaceWindow(WWindow *wwin, int *x_ret, int *y_ret,
unsigned width, unsigned
if (*y_ret usableArea.y1)
*y_ret = usableArea.y1;
}
+
+void get_right_position_on_screen(WScreen *scr, int *x, int *y, int size_x,
int size_y)
+{
+WMRect rect = wGetRectForHead(scr, wGetHeadForPointerLocation(scr));
+
+if (*x rect.pos.x)
+*x = rect.pos.x;
+
+if (*y rect.pos.y)
+*y = rect.pos.y;
+
+if (*x + size_x rect.pos.x + rect.size.width)
+*x = rect.pos.x + rect.size.width - size_x;
+
+if (*y + size_y rect.pos.y + rect.size.height)
+*y = rect.pos.y + rect.size.height - size_y;
+}
--
1.7.10.4
--
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: Problem with icons position
On 09/01/2013 9:11, Christian wrote: Hi, using a laptop with 2 monitors. the complete screen size is: 3200x1200 the left monitor (external) has: 1920x1200 (position 0 0) the right monitor (laptop) has: 1280x800 (position 1920x400) so I have unviewable area in upper right with a size of 1280x400 and my icons start just in this neverland. I can not see all of my icons, just the ones that will reach the viewable area of the right monitor. And to move the icons downwards I need to click on the 'top' icon, keep the mouse button pressed and then move it downwards. But how should I click on the top icon when I can't see it ? When I move the mouse to the neverland and do a right click to view the menu, this is automatically moved to the left (the viewable) area. So is it possible to do this with the ICONS, too ? Thanks in advance. Chris Hi, I understand your problem, but no why it happends. Is very interesting. In the code for menu, wmaker creates a WRect, and check the position. If is outside, move it inside. In the code for icons, wmaker creates a WArea, and check the position. If is outside, move it inside. If is wrong for icons, should be wrong for menu (or the functions are different and one is wrong). Ok, some questions. 1. Are you using Xinerama or Virtual desktop (I think yes). 2. Did you try with xrand? Can you try xrand, si something like (copy as script, or run it): 8 #!/bin/bash xrandr --output LVDS1 --mode 1280x800 xrandr --output VGA1 --mode 1920x1200 xrandr --output VGA1 --left-of LVDS1 8 I am running xrandr here without problems. You need restart windowmaker to move the icons to the right position. Then: 3. Is ok with xrandr? Then, we will continue :-) Cheers. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/7] Unify Dock and Clip
Try these patches :-) wmaker starts faster :-P The Clip doesn't blink in screen 0,0 coords. Cheers, kix On 30/03/2013 19:30, Rodolfo García Peñas (kix) wrote: From: Rodolfo García Peñas (kix) k...@kix.es This patch series do these things: - Unify the Dock and Clip creation because it uses one Clip per workspace and one common Dock. Clip and Dock do similar work then, the functions can handle them as WDock struct, without know if they are Clips or Docks. - Removes the extra Clip created in screen.h, used mainly to set the Clip icon and the position. - Set the final position for the Clip and Dock, without painting them in 0,0 and then move to the final position. - Remove the code where the Clip is created, removed and created again in the right position, because the Clip must be created after the workspace. The previous code create the Clip first, then remove it, and then Create it again in the workspace. - Easy event handle for mouse buttons in Clip and Dock, with menu creation in the WDock creation. Best regads, kix. Rodolfo García Peñas (kix) (7): dockMenuCreate splitted Dock middle button menu create Make clip_icon variable more private Remove X11 calls for Clip on workspace change Create clip only if needed New function set_appicon_positioh_from_dictionary Set position for all Dock types src/balloon.c |3 +- src/defaults.c |2 +- src/dock.c | 306 +++ src/dock.h |6 +- src/dockedapp.c |4 +- src/moveres.c |2 +- src/screen.c|8 +- src/workspace.c | 36 +++ src/workspace.h |2 +- 9 files changed, 196 insertions(+), 173 deletions(-) -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Docks and AppIcons
Andreas Tscharner a...@vis.ethz.ch escribió: On 20.03.2013 20:37, Rodolfo García Peñas (kix) wrote: [snip] Comments? Hi Andreas, You are using git. Make a branch and make the changes if you feel Yes, and no. I have a lot of branches here (Really, A LOT). When I send patches, is only a part of my branches here. like. If it does not work, you learned something. If it works we can review it here... Yes, but after the review, the patches should be uploaded. If Carlos thinks that we should work only in bugs, not in big/deep changes what will happend? Perhaps is not bad idea stop here for a while with deep changes. Saludos, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Docks and AppIcons
Hi, I was thinking about the docks and appicons in wmaker, and probably we should work in this code. Now, the Dock and the Clip are WDock structs, but the icons attached to the Clip or the Dock are WAppIcons. When we create the Dock/Clip we do something like: - Create the Dock (WDock struct) - Create a WAppIcon with the Dock image (WAppIcon struct) - Assign the Dock to the WAppIcon :-?!! That makes some things difficult. For example, we have different functions to create the Clip/Dock (wDockCreate()) or restore it (for example wClipRestoreState()), but these functions returns different structs (wDockCreate returns a WDock, wClipRestoreState a WAppIcon). Other example, with the Dock. The Dock is something like: 1. struct WAppIcon-dock is the pointer for the struct WDock 2. struct WDock has an icon_array, with WAppIcons. 3. The first WAppIcon in the array ([0]), is the WAppIcon for the dock Then, we have something like: WDock-icon_array[0]-dock = WDock Probably, the best option is assign a different WAppIcon struct for the Dock/Clip icon, outside the icon_array. Something like: WDock-icon_array for WAppIcons WDock-icon for the WAppIcon for the dock/clip. But, anyway, I think return WAppIcon when we are trying to create a WDock struct is wrong and all functions about Dock/Clip should work with WDock structs. Comments? Cheers, kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Change window border color
Renato Botelho rbga...@gmail.com escribió: Hello guys, After a long time, I'm back using windowmaker. I didn't find a way to change the window border color even looking at source code. Is it impossible to change it or am I missing something? Take a look in wcore.c: http://repo.or.cz/w/wmaker-crm.git/blob/066de301df2f07c614b77e7a2bbadd9ff1342e46:/src/wcore.c#l59 attribs.border_pixel = screen-frame_border_pixel; I don't know if you are talking about that. Saludos, kix Best regards -- Renato Botelho -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [Patch 0/2] Unify codepath for parsing generated and external menus
On 27/01/2013 18:24, Andreas Bierfert wrote:
Hi,
the following two patches change the parsing for generated menus
from external commands to use the same code path as externally
saved menus.
This way using an external menu file generated via 'wmmenugen
file' will actually do the same as running wmmenugen as command for
the generated menu (which currently just gives an empty menu for
me).
Regards, Andreas
Hi,
I didn't test your patches :-(
Some comments about the coding style.
1. The if{ should be if {
2. The else in patch 1 should include the bracket {.
+ pldata-ptr[0] = '\0';
+ }
+ else
+ pldata-ptr = wrealloc(pldata-ptr,
Cheers,
kix
--
||// //\\// 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 next updated: wmaker-0.95.4-16-gfd7b117
On 27/01/2013 17:03, BALATON Zoltan wrote: On Sat, 26 Jan 2013, crmafra wrote: If the user tries to set an icon (ignore flag is set) but the file textbox is not set we show the warning: Ignore client supplied icon is set, but icon filename textbox is empty. Using client supplied icon and use the client-supplied icon instead. Why not just make sure the option is only enabled when there's a file set and have it disabled and cleared otherwise? Having an option which only results in a warning if the user tries to enable it is not a good UI design. So I think the option should only be enabled when the file textbox is set and disabled if the user removes the file. I can't comment on Rodolfo's code changes because I can't follow the icon code so I try to only comment on the behaviour. I also saw a log message that said that the AlwaysUserIcon option is now saved always. That's bad in my opinion because it just makes config files harder to read without helping you in any way because the user will have old config files without this option so you should handle the case when the option is missing anyway. Thus it's better to only have Hi Zoltan, Carlos, The AlwaysUserIcon is saved only if the user edit the icon. I need save it to the attributes file because if I save only the textbox then is like the AlwaysUserIcon is set to true. There is not more difficult to understand the attributes file, is only one line more. OTOH, we can hold the last icon set in the textbox without use it, for example if the user want to use the icon sometimes, only open the winspector and then set or unset the flag. The patch is backward compatible, because if the textbox is set, then is because AlwaysUserIcon is true. two cases: AlwaysUserIcon option is present (with value Yes) or it's missing instead of also having AlwaysUserIcon=No; as a third case. You might consider this too for the final version of your patch. But in this case, the checkbox should be removed? If the textbox is set, then AlwaysUserIcon is true, and if is empty, AlwaysUserIcon is false. Best Regards, kix Regards, BALATON Zoltan -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/4] 3 Save iconpath if icon will be used
On 25/01/2013 11:53, BALATON Zoltan wrote:
On Fri, 25 Jan 2013, Carlos R. Mafra wrote:
On Fri, 25 Jan 2013 at 1:06:58 +0100, Rodolfo García Peñas wrote:
I changed the behavior for the winspector. Can you test it now?
More testers are welcome. If the patch is ok, I will write the commit
info.
I'm a bit lost about which behavior is being fixed. What is the test
case to aim for?
On the other hand, if Zoltan says it fixes his issues, I'll apply
without testing it myself :-)
I don't have time to test it now but I've described the problem, testing
procedure and provided a test case in the thread starting at
http://lists.windowmaker.org/dev/msg04395.html
The test case is here:
http://lists.windowmaker.org/dev/msg04396.html
(Should show a white rectangle in the app icon which is the icon window.)
The procedure to test Ignore app icon is here:
http://lists.windowmaker.org/dev/msg04452.html
Hope this helps.
Regards,
BALATON Zoltan
Hi Carlos, Zoltan,
I am changing the icon behavior in winspector.c, these cases:
1. ignore flag + file set
2. no ignore flag + file set
3. ignore flag + no file set
4. no ignore flag + no file set
I didn't change the xfig related problem.
About the patch, we have 8 different cases, 4 for apply and 4 for save.
Apply:
1. ignore flag + file set
2. no ignore flag + file set
3. ignore flag + no file set
4. no ignore flag + no file set
If the ignore client supplied icon flag is not set, then the user wants to
use the client (window/icon) provided image, so the file textbox don't matter.
Then, we use the client icon and we don't use the file provided in the text
box. Options 2 and 4 are done.
If the user set the flag, and set the icon name, perfect, the user provides the
icon. Option 1 is done.
The problem is if the user try to set an icon (ignore flag is set) but the file
textbox is not set (no icon provided). Now the code does:
1. Show a message box to the user with a warning. The warning show:
+ snprintf(buf, len, _(Ignore client supplied icon is
set, but icon filename textbox is empty. Using client supplied icon));
2. Unset the ignore flag and use the client provided icon. Is like we change
the case 3 to case 4:
Option 3 is done too.
This is the full code:
+ /* If always_user_icon flag is set, but the user icon is not set
+* we use client supplied icon and we unset the flag */
+ if ((WFLAGP(wwin, always_user_icon) (!file))) {
+ /* Show the warning */
+ char *buf;
+ int len = 100;
+ buf = wmalloc(len);
+ snprintf(buf, len, _(Ignore client supplied icon is
set, but icon filename textbox is empty. Using client supplied icon));
+ wMessageDialog(panel-frame-screen_ptr, _(Warning),
buf, _(OK), NULL, NULL);
+ wfree(buf);
+ wfree(file);
+
+ /* Change the flags */
+ WSETUFLAG(wwin, always_user_icon, 0);
+ WMSetButtonSelected(panel-alwChk, 0);
+ }
After these lines, we change the initial case 3 to the case 4, and then we can
apply the cases 1,2,4:
+ /* After test the always_user_icon flag value before,
+* the else block is used only if the flag is set and
+* the icon text box has an icon path */
+ if (!WFLAGP(wwin, always_user_icon)) { *- Cases 1,3*
+ /* Change App Icon image, using the icon provided by
the client */
if (wapp-app_icon)
+ wIconUpdate(wapp-app_icon-icon,
+
get_rimage_icon_from_wm_hints(wapp-app_icon-icon));
+
+ /* Change icon image if the app is minimized,
+* using the icon provided by the client */
+ if (wwin-icon)
+ wIconUpdate(wwin-icon,
get_rimage_icon_from_wm_hints(wwin-icon));
} else { *- Case 4 (and wrong 3*
/* Change App Icon image */
if (wapp-app_icon)
+ wIconChangeImageFile(wapp-app_icon-icon,
file);
/* Change icon image if the app is minimized */
if (wwin-icon)
+ wIconChangeImageFile(wwin-icon, file);
}
About the save, we do the same in the 4 options:
Now all is easier. We save the flag Yes or No always and we save the user
provided icon in the textbox.
Then, the user can see the last icon set in the textbox by the user always, if
the icon is used (flag is set) or not.
+ /* Save the icon info */
+ /* The flag Ignore client suplied icon is not selected */
+ buf1 = wmalloc(4);
+ snprintf(buf1, 4, %s,
Re: Release of source tarball for 0.95.4
Hi, I uploaded the Debian packages. They are in the experimental branch. Thanks John! Cheers, kix On 09/01/2013 22:57, Daniel Isenmann wrote: Thanks for releasing the tarball. I will build the Arch Linux package and will release it soon... Daniel John H. Robinson, IV jaq...@sbih.org schrieb: http://windowmaker.org/pub/source/release/WindowMaker-0.95.4.tar.gz Announcement coming soon. Sooner if someone else comes up with verbiage :D -john On Sat, Jan 5, 2013 at 1:55 AM, Daniel Isenmann daniel.isenm...@gmx.de mailto:daniel.isenm...@gmx.de wrote: Hi, thanks for this new release, but is it planned to release a source tarball at the usual place http://windowmaker.org/pub/source/release/ ? It's much easier to package and specify this source tarball file instead the one from the GIT repository in our PGKBUILD. Thanks Daniel -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org mailto: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: Reporting Bugs? (fwd)
On 06/01/2013 16:50, BALATON Zoltan wrote: Oops, wrong address... -- Forwarded message -- Date: Sun, 6 Jan 2013 16:46:15 +0100 (CET) From: BALATON Zoltan bala...@eik.bme.hu To: John Rash johnr...@gmail.com Cc: wmaker-de...@lists.windowmaker.org Subject: Re: Reporting Bugs? On 12/26/12, John Rashjohnr...@gmail.com wrote: and what really annoys me is how huge svg icons looks into docks (like from Nautilus/Caja (see that folder on the last icon), Chromium (that huge circle), etc.) - http://img803.imageshack.us/img803/4559/wmaker01.png - is there any I like the GNUstep cube logo on this screenshot. What do you think about making this the default dock icon instead of the current one which is now getting old and does not look good on new displays? +1 Is like the NeXT logo, with the wmaker logo :-) I'm adding the wmaker-users to get more votes (+1 or -1) Regards, BALATON Zoltan -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
