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)" escribió: This patch is mostly for testing. "Rodolfo García Peñas (kix)" 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) --- 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.
Help with appmenu [was: Re: Question about menus (usermenu, appmenu)]
Josip Deanovic 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. Hello, ok, the usermenu is now clear. IMO, we can improve this menu, for example to send text to xterms or similar (menu with "ssh -l user example.com" could be nice). But my problem now is related to appmenu. I don't know how this menu is used by the user, and how is configured. It includes X11 calls to create a menu and store it in wapp->menu (usermenu uses the same pointer). Help about it is very appreciated. 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)
Josip Deanovic 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)" 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) --- 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)" 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)
---
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 *
Re: Question about menus (usermenu, appmenu)
Quoting Josip Deanovic :
On Monday 2015-08-24 14:07:48 Rodolfo García Peñas wrote:
Josip Deanovic 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:
> ..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: Question about menus (usermenu, appmenu)
Josip Deanovic 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:
..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 BALATON Zoltan : On Sat, 22 Aug 2015, Josip Deanovic wrote: On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote: Which feature was removed that you are missing? The one I am talking for over a year now. :-) Also app icon caching was broken around the same time. The app icon cache in CachedPixmaps was meant to store icons retrieved from X clients so the dock or clip can display those when the client is not running like after startup. The cache should contain only such icons and the path should never appear in WMWindowAttributes because the cache is an internal thing used to look up icons not otherwise available. If you look at your WMWindowAttributes now it is full of entries referring to the cache that should not be there and if you look at the cache dir you'll find a lot of icons from all apps you've ever started while there should be only the few docked ones that use client side icons. Also the cache is never cleaned up only new icons are added to it. Hello, Yesterday I sent some patches to solve these problems. Could you try them? The icon handling code was a bit complicated before but worked (maybe cache cleanup was broken before) until overzealous simplification attempts have messed it up so much that it is now difficult to untangle. Even more so because the object oriented design was also messed up by renaming and moving methods around so now it is not clear what object methods these functions were meant to be. I think the principles to follow should be: 1. K.I.S.S. 2. If ain't broke don't fix it. 3. If you don't understand it don't touch it. (That is, think about all possible implications of your proposed change because it may work with your particular settings but a lot of things can be set by preferences.) I agree with you. But some things in windowmaker are not clear. Some code is old and/or unused. Most of my patches are related to K.I.S.S. and remove unused code. Removing usermenu and appmenu is because IMO, these menus are not used, but I am not sure (Is easy to find if one person is using it, but very difficult to kwow if nobody is using these menus). IMO we could remove these menus because: 1. Are not documented. The user don't know how to create/use the menu. 2. Are not examples, only in the source code we can find how to configure the menu. 3. The line to show the menu (in the source) is difficult to reach by the user. Cheers, kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic : On Sunday 2015-08-23 22:21:59 Carlos R. Mafra wrote: It is there now. I have compiled a newest version and tested every combination I could think of and works fine. No crash any more, feature works as expected. I would say that we can close this case. Thanks Josip, Regards, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic : On Sunday 2015-08-23 20:02:58 Rodolfo García Peñas wrote: Quoting Josip Deanovic : > On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: >> Solved. >> >> Thanks for your report. > > Thank you for the effort. > > I have just tested the code from the fresh next branch and > the issue still exist (Windowmaker crashes and restarts). Using the same steps? Yes. I have even relog (not just restart) to make sure that wmaker has been completely restarted. Thanks, I will continue with this problem tomorrow. I think I know the problem, but I need do a deep analysis. Regards, kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Quoting Josip Deanovic : On Sunday 2015-08-23 18:58:01 Rodolfo García Peñas wrote: Solved. Thanks for your report. Thank you for the effort. I have just tested the code from the fresh next branch and the issue still exist (Windowmaker crashes and restarts). Using the same steps? Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip Deanovic escribió: On Sunday 2015-08-23 18:32:06 Rodolfo García Peñas wrote: Hi Josip, confirmed, I am working on it. Thanks Cool. Thank you. Solved. Thanks for your report. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Regression fix (was Re: Question about menus (usermenu, appmenu))
Josip Deanovic escribió: Josip DeanovicOn Sunday 2015-08-23 19:25:32 wrote: On Sunday 2015-08-23 18:04:37 Carlos R. Mafra wrote: > Josip, the patch should fix the issue and it's in the #next > branch already. Would you mind testing it? I'll test it in the next 30 minutes. Ok, I have tested it and I can confirm that feature now works but while testing it I have encountered undesirable issues such as windowmaker crash and restart. So this is the procedure I used while testing: 1. I am using kwrite application for my tests 2. Start kwrite application on the command line 3. Checking Application Specific window attributes - No application icon - unselected - Shared application icon - selected 4. Drag the application icon to the dock 5. Enable (select) the option No application icon for the application 6. Close the application and run multiple instances of the application using double-click on the docked icon - everything works fine 7. In the application Specific menu disable (unselect) the option No application icon - windowmaker crashes and restarts -- Josip Deanovic Hi Josip, confirmed, I am working on it. Thanks Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Hi Carlos,
yes. I just sent the patch. Window Maker sometimes checks the flags,
sometimes only the pointers.
Cheers,
kix
"Carlos R. Mafra" escribió:
Rodolfo? Any ideas here?
On Sat, 22 Aug 2015 at 18:04:27 +0200, Josip Deanovic wrote:
On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote:
> On Sat, 22 Aug 2015 at 15:11:33 +0200, Josip Deanovic wrote:
> > Let's not remove anything until we find out what this really is.
> > There are some features still missing because of such actions in
> > the past.
>
> Which feature was removed that you are missing?
The one I am talking for over a year now. :-)
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
For the complete thread look for a subject "Double-click on application in
wmdock does not launch the application if one instance is already
running".
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about menus (usermenu, appmenu)
Hi Josip,
thanks for your report. Sorry about that. Patch is attached.
Perhaps we should use a different flag to run the application more
times from the same dock icon.
Cheers,
kix
Josip Deanovic escribió:
On Saturday 2015-08-22 16:53:56 Carlos R. Mafra wrote:
On Sat, 22 Aug 2015 at 15:11:33 +0200, Josip Deanovic wrote:
> Let's not remove anything until we find out what this really is.
> There are some features still missing because of such actions in
> the past.
Which feature was removed that you are missing?
The one I am talking for over a year now. :-)
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
For the complete thread look for a subject "Double-click on application in
wmdock does not launch the application if one instance is already
running".
--
Josip Deanovic
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
>From ccff70a14d18fb68b2869f1fe05d6069c9552b26 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20=28kix=29?=
Date: Sun, 23 Aug 2015 17:33:38 +0200
Subject: [PATCH] create_appicon_from_dock checks if no_appicon flag is set
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
As Josip Deanovic reported:
---8<---
In previous versions e.g. 0.80.2 up until 0.95.3 when an application
attributes are set with "NoAppIcon = Yes;" ("No application icon" option
in attributes window), it was possible to launch multiple instances of
the application from wmdock using double-click.
After doing a git bisect per your suggestion I have found and reported
this:
bc0700e016c67791d3e3eab855543d849f4ce786 is the first bad commit
commit bc0700e016c67791d3e3eab855543d849f4ce786
Author: Rodolfo GarcÃa Peñas (kix)
Date: Mon Jun 18 11:15:19 2012 +0200
Create WAppIcon always
When the application is created, the WAppIcon now is created always,
but it is only painted if the flag is not set.
The icon initialization to NULL can be done now at
app_icon_create_from_docks
because it is always called.
:04 04 7c58877ad5af211acaddac5288848c2ade7b04cb
33d52affb385d22fbf04ebad3c628b714008785d M src
---8<---
This patch reverts this change (not the patch). Now the function
create_appicon_from_dock checks if the flag no_appicon is set,
and then, do not execute the code related to the appicon.
Signed-off-by: Rodolfo García Peñas (kix)
---
src/appicon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/appicon.c b/src/appicon.c
index 302066d..08331c7 100644
--- a/src/appicon.c
+++ b/src/appicon.c
@@ -1180,7 +1180,7 @@ static void create_appicon_from_dock(WWindow *wwin, WApplication *wapp, Window m
}
/* If created, then set some flags */
- if (wapp->app_icon) {
+ if (wapp->app_icon && !WFLAGP(wapp->main_window_desc, no_appicon)) {
WWindow *mainw = wapp->main_window_desc;
wapp->app_icon->running = 1;
--
2.5.0
Re: Question about menus (usermenu, appmenu)
Hi,
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)" :
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" 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
"Carlos R. Mafra" escribió: On Sat, 15 Aug 2015 at 23:15:11 +0000, Rodolfo García Peñas (kix) wrote: Doug Torrance 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
Doug Torrance 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),
I did the changes to run using wmgeneral, are attached for your testing.
About the size, I don't know, I need more time.
Cheers,
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
>From b465e053f6153c477eba250ecab9305c6c658148 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20=28kix=29?=
Date: Sat, 15 Aug 2015 23:47:29 +0200
Subject: [PATCH 1/2] Include the wmbiff functions of wmgeneral.
The wmbiff application included some functions in wmgeneral. We need
include these functions in the libdockapp library. Probably we should
analize if these functions should be included in wmbiff and removed
from here.
---
libdockapp/src/wmgeneral.c | 39 +++
libdockapp/src/wmgeneral.h | 8
2 files changed, 47 insertions(+)
diff --git a/libdockapp/src/wmgeneral.c b/libdockapp/src/wmgeneral.c
index c624193..5511a31 100644
--- a/libdockapp/src/wmgeneral.c
+++ b/libdockapp/src/wmgeneral.c
@@ -84,6 +84,7 @@ Pixel back_pix, fore_pix;
Window iconwin, win;
GC NormalGC;
XpmIcon wmgen;
+XpmIcon wmgen_bkg;
Pixmap pixmask;
/*/
@@ -378,6 +379,44 @@ void copyXBMArea(int x, int y, int sx, int sy, int dx, int dy) {
}
+/* added for wmbiff */
+XFontStruct *f;
+int loadFont(const char *fontname)
+{
+ if (display != NULL) {
+ f = XLoadQueryFont(display, fontname);
+ if (f) {
+ XSetFont(display, NormalGC, f->fid);
+ return 0;
+ } else {
+ printf("couldn't set font!\n");
+ }
+ }
+ return -1;
+}
+
+void drawString(int dest_x, int dest_y, const char *string,
+const char *colorname, const char *bgcolorname,
+int right_justify)
+{
+ int len = strlen(string);
+ XSetForeground(display, NormalGC, GetColor((char *) colorname));
+ XSetBackground(display, NormalGC, GetColor((char *) bgcolorname));
+ if (right_justify)
+ dest_x -= XTextWidth(f, string, len);
+ XDrawImageString(display, wmgen_bkg.pixmap, NormalGC, dest_x, dest_y,
+ string, len);
+}
+
+void eraseRect(int x, int y, int x2, int y2, const char *bgcolorname)
+{
+ XSetForeground(display, NormalGC, GetColor((char *) bgcolorname));
+ XFillRectangle(display, wmgen_bkg.pixmap, NormalGC, x, y, x2 - x,
+ y2 - y);
+}
+
+/* end wmbiff additions */
+
/***\
|* setMaskXY *|
\***/
diff --git a/libdockapp/src/wmgeneral.h b/libdockapp/src/wmgeneral.h
index c3454c5..620f4de 100644
--- a/libdockapp/src/wmgeneral.h
+++ b/libdockapp/src/wmgeneral.h
@@ -86,4 +86,12 @@ void setMaskXY(int, int);
void parse_rcfile(const char *, rckeys *);
+/* for wmbiff */
+int loadFont(const char *fontname); /* -1 on fail, 0 success. */
+void drawString(int dest_x, int dest_y, const char *string,
+const char *colorname, const char *bgcolorname,
+int right_justify);
+void eraseRect(int x, int y, int x2, int y2, const char *bgcolorname);
+/* end wmbiff */
+
#endif
--
2.5.0
>From 1ccb7be60ad49b035e36ae056f8706f4f250c97e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20=28kix=29?=
Date: Sun, 16 Aug 2015 00:20:40 +0200
Subject: [PATCH 2/2] wmbiff
---
wmbiff/Makefile.am | 3 +-
wmbiff/configure.ac | 4 +-
wmbiff/wmbiff/Makefile.am| 4 +-
wmbiff/wmbiff/wmbiff.c | 27 +-
wmbiff/wmgeneral/Makefile.am | 10 -
wmbiff/wmgeneral/misc.c | 34 ---
wmbiff/wmgeneral/misc.h | 9 -
wmbiff/wmgeneral/wmgeneral.c | 621 ---
wmbiff/wmgeneral/wmgeneral.h | 69 -
9 files changed, 21 insertions(+), 760 deletions(-)
delete mode 100644 wmbiff/wmgeneral/Makefile.am
delete mode 100644 wmbiff/wmgeneral/misc.c
d
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)" 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)
---
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; i
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 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" 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.
Re: [PATCH] New library wmgeneral
"Alexey I. Froloff" 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: [PATCH] New library wmgeneral
"Alexey I. Froloff" 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. Hi Alexey, both, wmgeneral and libdockapp are used in a lot of applications: kix@kentin:~/src/dockapps$ rgrep wmgeneral * | cut -d/ -f1 | uniq -c | grep -v binar 1 dockapps.db.in:This app is based on the wmgeneral code." 105 libwmgeneral 57 wmbiff 4 wmCalClock 12 wmckgmail 10 wmcpufreq 14 wmfsm 13 wmifs 8 wmitime 10 wmkeys 4 wmmon 2 wmnotify 1 wmpower 11 wmppp.app 8 wmsm.app 5 wmSMPmon 7 wmsun 43 wmtime 5 wmtv 10 wmtz 2 wmWeather kix@kentin:~/src/dockapps$ rgrep libdockapp * | cut -d/ -f1 | uniq -c | grep -v binar | grep -v dockapps 26 libdockapp 14 wmacpi 2 wmacpiload 2 wmbatteries 2 wmcalendar 1 wmclock 10 wmcpuload 2 wmmemload 1 wmmenu 3 wmpower 5 wmwifi kix@kentin:~/src/dockapps$ Probably we should join both libraries in only one, but now, why do not create the libwmgeneral lib? There are more dockapps using libwmgeneral than libdockapp. As Doug said, with the new gcc version we need change a lot of dockapps, and this is the reason to create this library. The patch about the library is easy to include in the repo, we can update all dockapps using wmgeneral, remove the wmgenal folders and update the code. IMO is better have only one library than the same code in 20 different dockapps/folders. 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] make it possible to rename workspaces from "Workspace Menu"
BALATON Zoltan escribió: On Mon, 27 Jul 2015, Amadeusz Sławiński wrote: useful when there is no clip around It's already possible to do this by Ctrl+clicking the menu item. (You can even rename other than the current workspace with that.) Do we need another menu item for it? I agree, ctrl+click do it. IMO, no more functions/menu/code. 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?=
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 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 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 --- 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 23/23] Code refactoring: replaced macro 'XDND' by 'USE_DOCK_XDND' for consistency
On Thu, 25 Jun 2015, Rodolfo kix Garcia escribió: > On Sat, 13 Jun 2015, Christophe escribió: > > > > > ----- Rodolfo García Peñas a écrit : > > > On Mon, 06 Apr 2015, Christophe CURIS escribió: > > > > > > > diff --git a/configure.ac b/configure.ac > > > > index 4e55a94..6a02376 100644 > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -502,15 +502,16 @@ AS_IF([test "x$enable_modelock" = "xyes"], > > > > dnl XDND Drag-nd-Drop support > > > > dnl = > > > > AC_ARG_ENABLE([xdnd], > > > > -[AS_HELP_STRING([--disable-xdnd], [disable Drag-nd-Drop support])], > > > > +[AS_HELP_STRING([--disable-xdnd], [disable support for > > > > Drag-and-Drop on the dock @<:@default=enabled@:>@])], > > > > [AS_CASE(["$enableval"], > > > > [yes|no], [], > > > > [AC_MSG_ERROR([bad value $enableval for --disable-xdnd]) ]) ], > > > > [enable_xdnd=yes]) > > > > AS_IF([test "x$enable_xdnd" = "xyes"], > > > > -[supported_xext="$supported_xext XDnD" > > > > - AC_DEFINE([XDND], [1], [whether Drag-nd-Drop support should be > > > > enabled])], > > > > +[supported_core="$supported_core XDnD" > > > > + AC_DEFINE([USE_DOCK_XDND], [1], [whether Drag-and-Drop on the > > > > dock should be enabled])], > > > > [unsupported="$unsupported XDnd"]) > > > > +AM_CONDITIONAL([USE_DOCK_XDND], [test "x$enable_dock_xdnd" != "xno"]) > > > > > > > > > > > > dnl XShape support > > > > diff --git a/src/Makefile.am b/src/Makefile.am > > > > index 56ebe08..7fe9db7 100644 > > > > --- a/src/Makefile.am > > > > +++ b/src/Makefile.am > > > > @@ -84,7 +84,6 @@ wmaker_SOURCES = \ > > > > usermenu.c \ > > > > usermenu.h \ > > > > xdnd.h \ > > > > - xdnd.c \ > > > > xinerama.h \ > > > > xinerama.c \ > > > > xmodifier.h \ > > > > @@ -108,6 +107,9 @@ wmaker_SOURCES =\ > > > > wsmap.c \ > > > > wsmap.h > > > > > > > > +if USE_DOCK_XDND > > > > +wmaker_SOURCES += xdnd.c > > > > +endif > > > > if USE_MWM_HINTS > > > > wmaker_SOURCES += motif.h motif.c > > > > endif > > > > > > Hi, > > > > > > I am not sure if this patch is correct, because the xdnd.c file is > > > included always in the Makefile file, so the compiler try to use it. I am > > > not sure if I am missing something: > > > > > > kix@debian:~/src/wmaker/wmaker-crm$ ./configure --disable-xdnd >/dev/null > > > 2>&1 > > > kix@debian:~/src/wmaker/wmaker-crm$ grep xdnd.c src/* > > > src/Makefile:am__append_1 = xdnd.c > > > src/Makefile: wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ > > > src/Makefile.am:wmaker_SOURCES += xdnd.c > > > src/Makefile.in:@USE_DOCK_XDND_TRUE@am__append_1 = xdnd.c > > > src/Makefile.in:wmspec.c workspace.c workspace.h wsmap.c wsmap.h > > > xdnd.c \ > > > kix@debian:~/src/wmaker/wmaker-crm$ make distclean >/dev/null 2>&1 > > > kix@debian:~/src/wmaker/wmaker-crm$ ./configure >/dev/null 2>&1 > > > kix@debian:~/src/wmaker/wmaker-crm$ grep xdnd.c src/* > > > src/Makefile:am__append_1 = xdnd.c > > > src/Makefile: wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ > > > src/Makefile.am:wmaker_SOURCES += xdnd.c > > > src/Makefile.in:@USE_DOCK_XDND_TRUE@am__append_1 = xdnd.c > > > src/Makefile.in:wmspec.c workspace.c workspace.h wsmap.c wsmap.h > > > xdnd.c \ > > > kix@debian:~/src/wmaker/wmaker-crm$ date > > > dom jun 7 19:24:25 CEST 2015 > > > kix@debian:~/src/wmaker/wmaker-crm$ ls -l src/Makefile > > > -rw-r--r-- 1 kix kix 28709 jun 7 19:24 src/Makefile > > > kix@debian:~/src/wmaker/wmaker-crm$ > > > > > > Thanks for your reply, > > > Cheers, > > > kix. > > > > > > Hi, > > > > I confirm I can reproduce here too. > > The code is right, the issue comes because you need to re-run automake to > > regenerate the "Makefile.in", something that "con
Re: [PATCH 23/23] Code refactoring: replaced macro 'XDND' by 'USE_DOCK_XDND' for consistency
On Sat, 13 Jun 2015, Christophe escribió: > > - Rodolfo García Peñas a écrit : > > On Mon, 06 Apr 2015, Christophe CURIS escribió: > > > > > diff --git a/configure.ac b/configure.ac > > > index 4e55a94..6a02376 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -502,15 +502,16 @@ AS_IF([test "x$enable_modelock" = "xyes"], > > > dnl XDND Drag-nd-Drop support > > > dnl = > > > AC_ARG_ENABLE([xdnd], > > > -[AS_HELP_STRING([--disable-xdnd], [disable Drag-nd-Drop support])], > > > +[AS_HELP_STRING([--disable-xdnd], [disable support for Drag-and-Drop > > > on the dock @<:@default=enabled@:>@])], > > > [AS_CASE(["$enableval"], > > > [yes|no], [], > > > [AC_MSG_ERROR([bad value $enableval for --disable-xdnd]) ]) ], > > > [enable_xdnd=yes]) > > > AS_IF([test "x$enable_xdnd" = "xyes"], > > > -[supported_xext="$supported_xext XDnD" > > > - AC_DEFINE([XDND], [1], [whether Drag-nd-Drop support should be > > > enabled])], > > > +[supported_core="$supported_core XDnD" > > > + AC_DEFINE([USE_DOCK_XDND], [1], [whether Drag-and-Drop on the dock > > > should be enabled])], > > > [unsupported="$unsupported XDnd"]) > > > +AM_CONDITIONAL([USE_DOCK_XDND], [test "x$enable_dock_xdnd" != "xno"]) > > > > > > > > > dnl XShape support > > > diff --git a/src/Makefile.am b/src/Makefile.am > > > index 56ebe08..7fe9db7 100644 > > > --- a/src/Makefile.am > > > +++ b/src/Makefile.am > > > @@ -84,7 +84,6 @@ wmaker_SOURCES =\ > > > usermenu.c \ > > > usermenu.h \ > > > xdnd.h \ > > > - xdnd.c \ > > > xinerama.h \ > > > xinerama.c \ > > > xmodifier.h \ > > > @@ -108,6 +107,9 @@ wmaker_SOURCES = \ > > > wsmap.c \ > > > wsmap.h > > > > > > +if USE_DOCK_XDND > > > +wmaker_SOURCES += xdnd.c > > > +endif > > > if USE_MWM_HINTS > > > wmaker_SOURCES += motif.h motif.c > > > endif > > > > Hi, > > > > I am not sure if this patch is correct, because the xdnd.c file is included > > always in the Makefile file, so the compiler try to use it. I am not sure > > if I am missing something: > > > > kix@debian:~/src/wmaker/wmaker-crm$ ./configure --disable-xdnd >/dev/null > > 2>&1 > > kix@debian:~/src/wmaker/wmaker-crm$ grep xdnd.c src/* > > src/Makefile:am__append_1 = xdnd.c > > src/Makefile: wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ > > src/Makefile.am:wmaker_SOURCES += xdnd.c > > src/Makefile.in:@USE_DOCK_XDND_TRUE@am__append_1 = xdnd.c > > src/Makefile.in:wmspec.c workspace.c workspace.h wsmap.c wsmap.h > > xdnd.c \ > > kix@debian:~/src/wmaker/wmaker-crm$ make distclean >/dev/null 2>&1 > > kix@debian:~/src/wmaker/wmaker-crm$ ./configure >/dev/null 2>&1 > > kix@debian:~/src/wmaker/wmaker-crm$ grep xdnd.c src/* > > src/Makefile:am__append_1 = xdnd.c > > src/Makefile: wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ > > src/Makefile.am:wmaker_SOURCES += xdnd.c > > src/Makefile.in:@USE_DOCK_XDND_TRUE@am__append_1 = xdnd.c > > src/Makefile.in:wmspec.c workspace.c workspace.h wsmap.c wsmap.h > > xdnd.c \ > > kix@debian:~/src/wmaker/wmaker-crm$ date > > dom jun 7 19:24:25 CEST 2015 > > kix@debian:~/src/wmaker/wmaker-crm$ ls -l src/Makefile > > -rw-r--r-- 1 kix kix 28709 jun 7 19:24 src/Makefile > > kix@debian:~/src/wmaker/wmaker-crm$ > > > > Thanks for your reply, > > Cheers, > > kix. > > > Hi, > > I confirm I can reproduce here too. > The code is right, the issue comes because you need to re-run automake to > regenerate the "Makefile.in", something that "configure" does not do (it is > outside its scope). > > An simple solution is to do nothing: when you run "make" it will detect the > change when entering in the "src/" directory and automatically regenerate the > "Makefile.in", then it will re-generate the "Makefile". > > Another solution is to explicitly run "autogen.sh" before the "configure", > which might be better because it also runs "autoheader", something that the > Makefile will not do for you because the dependency
Re: [PATCH 23/23] Code refactoring: replaced macro 'XDND' by 'USE_DOCK_XDND' for consistency
On Mon, 06 Apr 2015, Christophe CURIS escribió: > diff --git a/configure.ac b/configure.ac > index 4e55a94..6a02376 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -502,15 +502,16 @@ AS_IF([test "x$enable_modelock" = "xyes"], > dnl XDND Drag-nd-Drop support > dnl = > AC_ARG_ENABLE([xdnd], > -[AS_HELP_STRING([--disable-xdnd], [disable Drag-nd-Drop support])], > +[AS_HELP_STRING([--disable-xdnd], [disable support for Drag-and-Drop on > the dock @<:@default=enabled@:>@])], > [AS_CASE(["$enableval"], > [yes|no], [], > [AC_MSG_ERROR([bad value $enableval for --disable-xdnd]) ]) ], > [enable_xdnd=yes]) > AS_IF([test "x$enable_xdnd" = "xyes"], > -[supported_xext="$supported_xext XDnD" > - AC_DEFINE([XDND], [1], [whether Drag-nd-Drop support should be > enabled])], > +[supported_core="$supported_core XDnD" > + AC_DEFINE([USE_DOCK_XDND], [1], [whether Drag-and-Drop on the dock > should be enabled])], > [unsupported="$unsupported XDnd"]) > +AM_CONDITIONAL([USE_DOCK_XDND], [test "x$enable_dock_xdnd" != "xno"]) > > > dnl XShape support > diff --git a/src/Makefile.am b/src/Makefile.am > index 56ebe08..7fe9db7 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -84,7 +84,6 @@ wmaker_SOURCES =\ > usermenu.c \ > usermenu.h \ > xdnd.h \ > - xdnd.c \ > xinerama.h \ > xinerama.c \ > xmodifier.h \ > @@ -108,6 +107,9 @@ wmaker_SOURCES = \ > wsmap.c \ > wsmap.h > > +if USE_DOCK_XDND > +wmaker_SOURCES += xdnd.c > +endif > if USE_MWM_HINTS > wmaker_SOURCES += motif.h motif.c > endif Hi, I am not sure if this patch is correct, because the xdnd.c file is included always in the Makefile file, so the compiler try to use it. I am not sure if I am missing something: kix@debian:~/src/wmaker/wmaker-crm$ ./configure --disable-xdnd >/dev/null 2>&1 kix@debian:~/src/wmaker/wmaker-crm$ grep xdnd.c src/* src/Makefile:am__append_1 = xdnd.c src/Makefile: wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ src/Makefile.am:wmaker_SOURCES += xdnd.c src/Makefile.in:@USE_DOCK_XDND_TRUE@am__append_1 = xdnd.c src/Makefile.in:wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ kix@debian:~/src/wmaker/wmaker-crm$ make distclean >/dev/null 2>&1 kix@debian:~/src/wmaker/wmaker-crm$ ./configure >/dev/null 2>&1 kix@debian:~/src/wmaker/wmaker-crm$ grep xdnd.c src/* src/Makefile:am__append_1 = xdnd.c src/Makefile: wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ src/Makefile.am:wmaker_SOURCES += xdnd.c src/Makefile.in:@USE_DOCK_XDND_TRUE@am__append_1 = xdnd.c src/Makefile.in:wmspec.c workspace.c workspace.h wsmap.c wsmap.h xdnd.c \ kix@debian:~/src/wmaker/wmaker-crm$ date dom jun 7 19:24:25 CEST 2015 kix@debian:~/src/wmaker/wmaker-crm$ ls -l src/Makefile -rw-r--r-- 1 kix kix 28709 jun 7 19:24 src/Makefile kix@debian:~/src/wmaker/wmaker-crm$ Thanks for your reply, Cheers, kix. -- 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 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 --- 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: [PATCH 15/23] doc: convert INSTALL-WMAKER into a texinfo source processed by texi2txt
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 > --- 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.
Re: Wayland support?
Quoting BALATON Zoltan : 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: Wayland support?
Johann Haarhoff 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.
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
Christophe escribió: - Rodolfo García Peñas 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.
Re: [PATCH 1/4] WINGs: add functions to set widget background image
Hello, I am not sure, but this patch is not the patch in the git. There are other patches about that later? The difference is: > -WINGS_AGE=0 > +WINGS_AGE=1 But in the git WINGS_AGE=0. Cheers, kix On Wed, 10 Dec 2014, David Maciejak escribió: > ok patch enclosed. > > Carlos could you please amend commit 467b7ee4560f124f7469a2a630cb35d477cc0444 > ? > > thx, > david > > [PATCH] WINGs: increment version > > This patch is incrementing version number as the API changed. > --- > WINGs/WINGs/WINGs.h | 2 +- > configure.ac| 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/WINGs/WINGs/WINGs.h b/WINGs/WINGs/WINGs.h > index ca7be55..4798174 100644 > --- a/WINGs/WINGs/WINGs.h > +++ b/WINGs/WINGs/WINGs.h > @@ -26,7 +26,7 @@ > #include > #include > > -#define WINGS_H_VERSION 20140612 > +#define WINGS_H_VERSION 20141205 > > > #ifdef __cplusplus > diff --git a/configure.ac b/configure.ac > index d7ccdae..326710d 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -47,9 +47,9 @@ > WRASTER_VERSION=$WRASTER_CURRENT:$WRASTER_REVISION:$WRASTER_AGE > AC_SUBST(WRASTER_VERSION) > dnl > dnl libWINGs > -WINGS_CURRENT=3 > +WINGS_CURRENT=4 > WINGS_REVISION=0 > -WINGS_AGE=0 > +WINGS_AGE=1 > WINGS_VERSION=$WINGS_CURRENT:$WINGS_REVISION:$WINGS_AGE > AC_SUBST(WINGS_VERSION) > dnl > -- > 2.1.0 > > On Mon, Dec 8, 2014 at 9:02 PM, Alexey I. Froloff wrote: > > On Fri, Dec 05, 2014 at 10:13:34AM +0800, David Maciejak wrote: > >> -WINGS_CURRENT=3 > >> +WINGS_CURRENT=4 > >> WINGS_REVISION=0 > >> WINGS_AGE=0 > > I should read more docs, before suggesting. WINGS_AGE should > > also be increased according to info libtool... > > > > -- > > Regards,-- > > Sir Raorn. --- https://plus.google.com/+AlexeyFroloff -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Question about nopolling variable
"Carlos R. Mafra" escribió: On Mon, 8 Dec 2014 at 17:46:25 +0000, Rodolfo García Peñas (kix) wrote: "Carlos R. Mafra" 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: Question about nopolling variable
"Carlos R. Mafra" 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? 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
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. kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Question about nopolling variable
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$ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/4] WINGs: add functions to set widget background image
Hi, I think is better increase the REVISION number instead of the WINGS_CURRENT when we are *adding* new functions. The new revision has backward compatibility with previous versions of wmaker, so IMO is better hold the library version number. We should avoid remove functions, because other applications could use them. OTOH IMO we should change the library version number only one time in every wmaker release. Cheers, kix On Fri, 05 Dec 2014, David Maciejak escribió: > This patch is incrementing version number as the API changed. > > --- > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index 7097e9d..1dbba92 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -47,7 +47,7 @@ > WRASTER_VERSION=$WRASTER_CURRENT:$WRASTER_REVISION:$WRASTER_AGE > AC_SUBST(WRASTER_VERSION) > dnl > dnl libWINGs > -WINGS_CURRENT=3 > +WINGS_CURRENT=4 > WINGS_REVISION=0 > WINGS_AGE=0 > WINGS_VERSION=$WINGS_CURRENT:$WINGS_REVISION:$WINGS_AGE > -- > 2.1.0 > > On Thu, Dec 4, 2014 at 5:47 PM, Alexey I. Froloff wrote: > > On Thu, Dec 04, 2014 at 04:08:41PM +0800, David Maciejak wrote: > >> +void WMSetWidgetBackgroundPixmap(WMWidget *w, WMPixmap *pix); > >> + > >> +WMPixmap *WMGetWidgetBackgroundPixmap(WMWidget *w); > >> + > > New public functions are added to the library. WINGS_VERSION > > should be changed as described in info libtool (Updating version > > info) - increment WINGS_CURRENT and set WINGS_REVISION to 0. > > > > -- > > Regards,-- > > Sir Raorn. --- https://plus.google.com/+AlexeyFroloff -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ 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" escribió: On Thu, 6 Nov 2014 at 10:33:43 +0000, Rodolfo García Peñas (kix) wrote: "Carlos R. Mafra" escribió: >On Thu, 6 Nov 2014 at 9:35:53 +0000, 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: [PATCH 00/13] A bunch of small stuff for #next
"Carlos R. Mafra" escribió: On Thu, 6 Nov 2014 at 9:35:53 +0000, 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
Christophe escribió: From: Christophe CURIS 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] wmaker: Restore multi screen functionality by reverting wrong commits
Hello,
please, how can I reproduce the problem?
Thanks a lot,
Rodolfo.
BALATON Zoltan 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 dock */
-
Re: [PATCH] Test to remove code
Quoting "Carlos R. Mafra" : On Tue, 26 Aug 2014 at 12:44:31 +0800, David Maciejak wrote: [snip] Change the 10 to 1, and move your dock on the right side. You should be able to see something ;) Indeed, something must be done about the speed, it's too fast. In set the animation speed to 'ultraslow' in WPrefs but even that is too fast. Anyway, maybe the default delay value should be updated ? Probably yes. I haven't seen the code doing the animation for a long time though. IMO no, at least not only. If we change the timeout, we will have an icon "jumping" on the screen. The Appicon is painted only 5 or 6 times on the screen moving from the appicon list to the Dock/Clip/Drawer. While the icon is moving, in the wsleeps, wmaker is stopped, and the application is not launched. Please, to test it, modify the wsleep time as David pointed, and you will see what I'm saying. IMO, the right code is painting the icon more times on the screen. Every X (5? 10?) pixels or something like. Then, the icon is moving (not jumping). and wmaker can do it faster (now, video cards and computers are faster). We need change (probably a lot) the function SlideWindows (src/misc.c). Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Could we remove this code?
Hi, I sent "[PATCH] Test to remove code" related to this issue. IMO, probably we should remove it. Cheers, kix "Carlos R. Mafra" escribió: On Sat, 23 Aug 2014 at 22:12:39 +0000, Rodolfo García Peñas (kix) wrote: is possible remove this code? I did it and no differences :-/ I think there are two options: 1. If you can prove that the code is never executed you can safely remove it 2. If the code can be executed, you can explain what it's supposed to do and argue why wmaker doesn't really need to do that. I like to get rid of code in general, so I'm open to hear explanations of why we don't need that code. If it makes sense and people agree, we can remove it. -- 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.
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: Problem with stacking
David Maciejak 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)"?=
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.
Re: [PATCH] wmaker: src/action.c merge duplicate code
"Rodolfo García Peñas (kix)" escribió:
David Maciejak escribió:
No problem i understand, enclosed the new patch.
Hi David,
is possible remove the extra curly brackets (in both "if"s)?:
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: [PATCH] wmaker: src/action.c merge duplicate code
David Maciejak escribió:
No problem i understand, enclosed the new patch.
Hi David,
is possible remove the extra curly brackets (in both "if"s)?:
+ 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: Window Maker Fork
David Maciejak escribió: On Monday, August 18, 2014, Josip Deanovic wrote: Quoting message written on Sunday 2014-08-17 18:07:08 by Charles Philip Chan: > On 17 Aug 2014, k...@kix.es 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 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.
Re: [PATCH] wmaker: fix moveres.c compilation warning
Hi David,
Nice patch. Probably is a good idea remove the dx variable in the function
getResizeDirection() too, to avoid this compiler warning:
gcc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/local/lib/locale\" -I../wrlib
-I../WINGs -I/usr/local/include -DNDEBUG -D_XOPEN_SOURCE=600 -D_GNU_SOURCE
-g -O2 -std=c11 -Wall -Wextra -Wno-sign-compare -Wno-deprecated
-Wno-deprecated-declarations -MT moveres.o -MD -MP -MF .deps/moveres.Tpo -c -o
moveres.o moveres.c
moveres.c: In function ‘getResizeDirection’:
moveres.c:1801:65: warning: unused parameter ‘dx’ [-Wunused-parameter]
static int getResizeDirection(WWindow * wwin, int x, int y, int dx, int dy,
int flags)
Cheers,
kix
On Thu, 14 Aug 2014, David Maciejak escribió:
> This patch is fixing compilation issue as variable 'dx'
> is not used in getResizeDirection function
> ---
> src/moveres.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/moveres.c b/src/moveres.c
> index 3d707d7..6645b22 100644
> --- a/src/moveres.c
> +++ b/src/moveres.c
> @@ -1803,6 +1803,7 @@ static int getResizeDirection(WWindow * wwin,
> int x, int y, int dx, int dy, int
> int w = wwin->frame->core->width - 1;
> int cw = wwin->frame->resizebar_corner_width;
> int dir;
> + (void) dx;
>
> /* if not resizing through the resizebar */
> if (!(flags & RESIZEBAR)) {
> --
--
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 escribió: From: Christophe CURIS 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: [repo.or.cz] wmaker-crm.git branch next updated: wmaker-0.95.5-239-gc54d294
On Fri, 31 Jan 2014, Carlos R. Mafra escribió: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project wmaker-crm.git. > > The branch, next has been updated >via c54d29464894050927854a2ee7b2495ea86de7fa (commit) > from dc0062f37a818fc708a85e43ed782b1f16b43e51 (commit) Could you upload the other patches and upload it to github too? Thanks. kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: We need the test folder?
On Fri, 31 Jan 2014, Carlos R. Mafra escribió:
> On Fri, 31 Jan 2014 at 20:19:35 +0100, Rodolfo García Peñas wrote:
> > Hi,
> >
> > wmaker includes the ./test folder. We need this folder? Could be removed?
>
> I'd rather keep it, for educational purposes.
Patch attached.
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
>From 41f57891db17339f46d379a5d53dff8c4ad0454e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rodolfo=20Garc=C3=ADa=20Pe=C3=B1as=20=28kix=29?=
Date: Fri, 31 Jan 2014 20:55:32 +0100
Subject: [PATCH] remove wtest compiler warnings.
This patch removes the wtest compiler warnings.
---
test/wtest.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/test/wtest.c b/test/wtest.c
index 8490e9c..c886c5b 100644
--- a/test/wtest.c
+++ b/test/wtest.c
@@ -29,18 +29,24 @@ Display *dpy;
Window leader;
WMAppContext *app;
-static void callback(void *foo, int item, Time time)
+static void callback(int item)
{
+ (void) item;
+
printf("pushed item %i\n", item);
}
-static void quit(void *foo, int item, Time time)
+static void quit(int item)
{
+ (void) item;
+
exit(0);
}
-static void hide(void *foo, int item, Time time)
+static void hide(int item)
{
+ (void) item;
+
WMHideApplication(app);
}
@@ -52,11 +58,12 @@ WMMenu *menu;
WMMenu *submenu;
int wincount = 0;
-static void newwin(void *foo, int item, Time time)
+static void newwin(int item)
{
Window win;
XClassHint classhint;
char title[100];
+ (void) item;
wincount++;
win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 10 * wincount, 10 * wincount, 200, 100, 0, 0, 0);
@@ -76,10 +83,6 @@ static void newwin(void *foo, int item, Time time)
attr.miniaturize_pixmap = XCreateBitmapFromData(dpy, DefaultRootWindow(dpy), bits, 10, 10);
attr.miniaturize_mask = XCreateBitmapFromData(dpy, DefaultRootWindow(dpy), mbits, 10, 10);
- /*
- attr.flags |= GSWindowStyleAttr;
- attr.window_style = NSTitledWindowMask|NSClosableWindowMask;
- */
WMSetWindowAttributes(dpy, win, &attr);
@@ -106,6 +109,7 @@ int main(int argc, char **argv)
miniaturize_win = XInternAtom(dpy, "_GNUSTEP_WM_MINIATURIZE_WINDOW", False);
leader = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 10, 10, 10, 10, 0, 0, 0);
+
/* set class hint */
classhint.res_name = "test";
classhint.res_class = "Test";
@@ -138,7 +142,7 @@ int main(int argc, char **argv)
XSetCommand(dpy, leader, argv, argc);
/* create first window */
- newwin(NULL, 0, 0);
+ newwin(0);
XFlush(dpy);
puts("Run xprop on the test window to see the properties defined");
--
1.8.5.2
We need the test folder?
Hi, wmaker includes the ./test folder. We need this folder? Could be removed? kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ 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 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: Unix cycling works backwards for some configurations
Hello Florian, thanks for your quick reply. With your examples, now I think I can understand it. Your behaviour is that the window sort is static, so with your four windows: W1 - W2 - W3 - W4 The FocusNext (and FocusPrevKey) event moves in one direction, but the window sort doesn't change (parentesis is the selected window): Current status: (W1) - W2 - W3 - W4 FocusNextKey + release: W1 - (W2) - W3 - W4 FocusNextKey + release: W1 - W2 - (W3) - W4 FocusNextKey + release: W1 - W2 - W3 - (W4) FocusPrevKey + release: W1 - W2 - (W3) - W4 FocusPrevKey + release: W1 - (W2) - W3 - W4 FocusPrevKey + release: (W1) - W2 - W3 - W4 But the current wmaker behaviour is that, when the window is selected, it is moved to the top of the window list: Current status: (W1) - W2 - W3 - W4 FocusNextKey + release: (W2) - W1 - W3 - W4 FocusNextKey + release: (W1) - W2 - W3 - W4 FocusNextKey + FocusNextKey + release: (W3) - W1 - W2 - W4 As you say in the previous mail is that your behaviour was included in wmaker 0.80.0, but was removed in 0.91.0, and the option "WindozeCycling = NO;" doesn't do nothing. So, I will forward this mail to upstream. More info at [1] Again, thanks a lot for your bug report, Regards, kix [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290777 On Sun, 08 Dec 2013, Florian Siegesmund escribió: > Hello kix, > > On Sat 2013-12-07, Rodolfo García Peñas wrote: > > > I think this bug can be closed. I tried it now and I don't have these > > issues. > > IBTD, I'm afraid. > > I still have set > > FocusNextKey = "Shift+Mod1+Tab"; > FocusPrevKey = "Mod1+Tab"; > > to get close to the desired behaviour. > > Desired behaviour: > > * open 4 different applications, e.g. xterm1, xterm2, xterm3, xterm4 > * now xterm4 has the focus > * press ALT+TAB and release the keys > * xterm1 has the focus > * press ALT+TAB and release the keys > * xterm2 has the focus > * press ALT+TAB and release the keys > * xterm3 has the focus > * press ALT+TAB and release the keys > * xterm4 has the focus > * press ALT+TAB and release the keys > * xterm1 has the focus > * [...] > * xterm1 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm4 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm3 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm2 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm1 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm4 has the focus > * [...] > > Here is what I get with my current settings: > > * open 4 different applications, e.g. xterm1, xterm2, xterm3, xterm4 > * now xterm4 has the focus > * press ALT+TAB and release the keys > * xterm1 has the focus > * press ALT+TAB and release the keys > * xterm2 has the focus > * press ALT+TAB and release the keys > * xterm3 has the focus > * press ALT+TAB and release the keys > * xterm4 has the focus > * press ALT+TAB and release the keys > * xterm1 has the focus > * [...] > * xterm1 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm4 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm1 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm4 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm1 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm4 has the focus > * [...] > > So FocusPrevKey is running in the wrong direction and FocusNextKey > is working completely wrong (this ist stack instead of cycling). > > Now let's try to set: > > FocusNextKey = "Mod1+Tab"; > FocusPrevKey = "Shift+Mod1+Tab"; > > Result: > > * open 4 different applications, e.g. xterm1, xterm2, xterm3, xterm4 > * now xterm4 has the focus > * press ALT+TAB and release the keys > * xterm3 has the focus > * press ALT+TAB and release the keys > * xterm4 has the focus > * press ALT+TAB and release the keys > * xterm3 has the focus > * press ALT+TAB and release the keys > * xterm4 has the focus > * press ALT+TAB and release the keys > * xterm3 has the focus > * [...] > * xterm3 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm1 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm2 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm4 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm3 has the focus > * press ALT+SHIFT+TAB (and release) > * xterm1 has the focus > * [...] > > Version information: > > | > wmaker -version > | Window Maker 0.95.3 > | > cat /etc/debian_version > | 7.2 > | > > > > If you agree, I will close the bug. > > I am sorry, but not fixed for me. > > Best Regards > > Sonny > > -- > :wq -- .''`. Rodolfo García Peñas (kix) : :' : Proud Debian Developer `. `'` 4096R / 3F48 0B8C C385 AD41 9E28 006A 7B1F 5490 72B7 4923 `- Debian - when you have better things to do than fixing systems -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
wmmon patch. Was (fwd) Re: CPU usage gets progressively more unreliable
Hi, what do you think about this patch for wmmon? The question is about the "long long" and the cc/gcc compiler change. Cheers, kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ --- Begin Message --- Rodolfo García Peñas wrote, On 2013-12-06 22:34: > Hi Pedro, > > I was checking the wmmon code, and I didn't find the problem. I think wmmon > reads the /proc/stat file using long, not using floats. > > Could you check it again? > Hello, Rodolfo, I'm sorry. I use three monitoring utilities at the same time, and all three needed patching because they were affected by the same problem, namely that the numbers in the jiffy counters can grow beyond what these tools are prepared to handle. The utilities are wmmon, wmcpu, and wmtop. I just confused wmmon with wmcpu and sent it to the wrong package. My apologies. However, this bug can still be usable for the part that affects wmmon. The problem in this case only affects long running machines using 32-bit longs (i386 in particular), and happens when the jiffy counter needs more than 32 bits to be represented (that's why they have to be long-running). The attached patch is not intended to be applied directly to close this bug; it's a "works for me" but it is likely to break packaging policies or builds due to unconditional use of certain C features (long long type, to be precise). It's also not clean in the sense that it uses "#if 0" ... "endif" to comment out a section of the code. I'm far behind in compilers, autotools, Debian build system and C dialects as to be able to turn it into a complete patch, but it will hopefully highlight where the problem lies and enable someone else to turn it into a complete solution. It's done against the previous version, 1.1+20120402-1. I don't think it will apply cleanly to 1.1+20131205 after the joining of several variables into a single line, but I haven't tried. Thanks for looking into this. I will submit a separate report to wmcpu with the previous patch I sent. Pedro Gimeno diff -ru wmmon-1.1+20120402/debian/changelog wmmon-1.1+20120402-new/debian/changelog --- wmmon-1.1+20120402/debian/changelog 2012-04-18 21:09:11.0 +0200 +++ wmmon-1.1+20120402-new/debian/changelog 2013-05-21 16:21:52.0 +0200 @@ -1,3 +1,10 @@ +wmmon (1.1+20120402-1pgimeno) unstable; urgency=low + + * wmmon.c +- Fix overflow with longs + + -- Pedro Gimeno Wed, 23 Apr 2012 14:11:00 +0100 + wmmon (1.1+20120402-1) unstable; urgency=low * New upstream version. diff -ru wmmon-1.1+20120402/wmmon/Makefile wmmon-1.1+20120402-new/wmmon/Makefile --- wmmon-1.1+20120402/wmmon/Makefile 2012-04-16 12:47:01.0 +0200 +++ wmmon-1.1+20120402-new/wmmon/Makefile 2013-05-21 16:20:57.0 +0200 @@ -6,7 +6,7 @@ ../wmgeneral/list.o CFLAGS = -O2 -CC = cc +CC = gcc .c.o: diff -ru wmmon-1.1+20120402/wmmon/wmmon.c wmmon-1.1+20120402-new/wmmon/wmmon.c --- wmmon-1.1+20120402/wmmon/wmmon.c 2012-04-16 12:47:01.0 +0200 +++ wmmon-1.1+20120402-new/wmmon/wmmon.c 2013-05-21 22:57:22.0 +0200 @@ -130,6 +130,8 @@ #define HISTORY_ENTRIES 55 +typedef long long llong; + // /* Global Variables */ // @@ -218,14 +220,14 @@ int his[HISTORY_ENTRIES]; int hisaddcnt; long rt_stat; - long statlast; + llong statlast; long rt_idle; - long idlelast; + llong idlelast; /* Processors stats */ long *cpu_stat; - long *cpu_last; + llong *cpu_last; long *idle_stat; - long *idle_last; + llong *idle_last; } stat_dev; @@ -241,10 +243,10 @@ int getNbCPU(void); unsigned long getWidth(long, long); int checksysdevs(void); -void get_statistics(char *, long *, long *, long *, long *, long *); +void get_statistics(char *, long *, llong *, llong *, llong *, llong *); void DrawActive(char *); -void update_stat_cpu(stat_dev *, long *, long *); +void update_stat_cpu(stat_dev *, llong *, llong *); void update_stat_io(stat_dev *); void update_stat_mem(stat_dev *st, stat_dev *st2); void update_stat_swp(stat_dev *); @@ -269,10 +271,10 @@ long curtime; long nexttime; - long istat; - long idle; - long *istat2; - long *idle2; + llong istat; + llong idle; + llong *istat2; + llong *idle2; FILE *fp; char *conffile = NULL; @@ -339,9 +341,9 @@ nb_cpu = getNbCPU(); stat_device[0].cpu_stat = calloc(nb_cpu, sizeof(long)); - stat_device[0].cpu_last = calloc(nb_cpu, sizeof(long)); + stat_device[0].cpu_last = calloc(nb_cpu, sizeof(llong)); stat_device[0].idle_stat = calloc(nb_cpu, sizeof(long)); - stat_device[0].idle_last = calloc(nb_cpu, sizeof(long)); + stat_device[0].idle_last = calloc(nb_cpu, sizeof(llong)); if (!stat_device[0].cpu_stat || !stat_device[0].cpu_last || !stat_device[0].idle_stat @@ -349,8 +351,8 @@ fprintf(stderr, "%s: Unable to alloc memory !\n", argv[0]); exit(1); } - is
Re: [PATCH] wmmon bug fixes
On Thu, 05 Dec 2013, Carlos R. Mafra escribió: > On Thu, 5 Dec 2013 at 13:26:21 +1300, Len Trigg wrote: > > Hi there, > > > > I just switched back to wmaker after many years away (thanks Doug for > > the Ubuntu PPA). I found a couple of bugs in wmmon, addressed by the > > attached patch against current dockapps git. > > Thanks, it's in the repo now. Uploaded to Debian. Cheers. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Tooltip problem
Hi, try this: 1. Run iceweasel (firefox if not debian) 2. ps ax | grep iceweasel and get the PID 3. sleep 10; kill -STOP iceweaselpid 4. move quickly (you have 10 seconds) the mouse to a iceweasel tab. The tab show the tooltip 5. wait 10 seconds... 6. Change the workspace. The tooltip will stay up This behaviour is related to Debian bug 409194 [1] Cheers, kix [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409194 -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Windows list not sorted by workspace
Hi, The Debian bug number 280851 [1] reports that the window list is not sorted by workspace. This is not a bug, but could be a good idea. When I open a new window in other workspace, or move the window between workspaces, the window list is updated, but is not sorted by workspace. Could we sort the window list by workspaces? (and update it when the windows are moved,...). Cheers, kix [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280851 -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Using multiple configuration files
On Tue, 03 Dec 2013, Rodolfo kix Garcia escribió: > Hi, > > I think this idea is very interesting. Vasilis reported that wmaker doesn't > read the system-wide WMGLOBAL configuration file, only the users file. > > Probably could be a good idea "merge" both files. Read the sytem global conf > file, read the user conf file, merge both files and create the final > configuration. The user conf file should overwrite the previous loaded system > configuration. > > In many systems, the user configuration file could be empty (or no exists). > > What do you think? > > Cheers, > kix You can read more about this bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172219 kix. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Using multiple configuration files
Hi, I think this idea is very interesting. Vasilis reported that wmaker doesn't read the system-wide WMGLOBAL configuration file, only the users file. Probably could be a good idea "merge" both files. Read the sytem global conf file, read the user conf file, merge both files and create the final configuration. The user conf file should overwrite the previous loaded system configuration. In many systems, the user configuration file could be empty (or no exists). What do you think? Cheers, kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Option to disable icons
Hi,
there is a Debian bug about a possible option to disable icons [1]
---8<---
I would like an option to disable the wmaker icons.
I like the dock, I like the window manager, but I don't want the icons.
They take space off my desktop and Gnome already does that. I don't need
them
This should be probably forwarded to upstream.
The only option right now is to suppress the icons for each individual
program ('No application icon' option).
It is not practical.
---8<---
If the user disable the app icon with "No application icon", the appicon is
disabled too, but this is not the desired behaviour.
Is possible to do that with the current wmaker version (this bug has 11
years...)? I mean disable all application icons.
Cheers,
kix
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149898
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Alt+Tab popup
On Mon, 02 Dec 2013, Chris Jones escribió: > On Mon, Dec 02, 2013 at 01:37:42PM EST, Josip Deanovic wrote: > > On Monday 2013-12-02, Chris Jones wrote: > > > > I disabled the Al+Tab popup that visualizes your open windows on my > > > main account years ago. While setting up a test account on the same > > > machine I noticed that this feature was enabled by default. I assume > > > this was also the case with my main account and that I figured out > > > how to disable it at the time.. but for the life of me I cannot > > > remember how. I went through all the options in WPrefs and didn't > > > see anything that looks related. > > > > Would anyone know off the top of their head how you can achieve > > > this..? > > > > Thanks, > > > In my opinion that switch panel is aesthetically the least attractive > > Windowmaker's feature (mostly because of it's default blue color that > > just doesn't fit). The decision to enable this feature by default and > > not providing an option in WPrefs to disable it definitely isn't the > > best decision made by Windowmaker developers/maintainers. > > > > You can disable it by adding this option to your Windowmaker file: > > SwitchPanelImages = None; Hi, probably could be a good idea include it in WPrefs, to avoid add it manually. > Great.. I still don't remember ever doing that in my main account.. But > then its config files result from 10+ years of debian upgrades starting > long before this feature was implemented... so who knows... > > Won't argue about the looks of this popup.. I never look at it anyway. > So where I'm concerned it's just an annoying distraction :-) > > Since there's an FAQ of sorts at the wmaker site, maybe s/o could add it > to the list..? > > In any case, thanks much for prompt reply..! > > CJ > > P.S. Does anyone know why the info panel "easter egg" was removed from > current versions...? I use my randomly-chosen e-mail signature among > those wonderful tidbits of Window Maker history as my signature--as some > will no doubt have noticed. The easter egg was removed here: http://repo.or.cz/w/wmaker-crm.git/commit/f9792a042a5446197326b730f88e4b2de1eb8574 Cheers, kix > -- > Alex Perez is aliv!!! > > > -- > To unsubscribe, send mail to wmaker-user-unsubscr...@lists.windowmaker.org. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Problem with Super_L keycode
Hi, there is a Debian bug (#140181) [1] about this problem: ---8<--- I tried to act left win key (between ctrl_l and alt_l) as F12 key. F12 shows application menu. But it doesn't work. xev showed this key as keysym F12 when i pressed it. WPrefs worked same way too when i tried to change shortcut. In WPrefs this key worked as F12 (i scanned it in shortcuts section). So problem is that right keysym is generated, xev and WPrefs detect it as F12 but Windowmaker doesn't respond to press of it. Of course i tried to put xmodmap in .xinitrc but without success. ---8<--- The problem was reported in version 0.79.0, but I tried it here, and the current +version 0.95.5 continues with this problem. Cheers, kix [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140181 -- .''`. Rodolfo García Peñas (kix) : :' : Proud Debian Developer `. `'` 4096R / 3F48 0B8C C385 AD41 9E28 006A 7B1F 5490 72B7 4923 `- Debian - when you have better things to do than fixing systems -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Github repository
"Carlos R. Mafra" 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 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: 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 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. kill John!! >> 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.
(fwd) wmaker 0.95.5-1 MIGRATED to testing
Hi, fyi, the new release 0.95.5-1 was uploaded to testing. Cheers, kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ --- Begin Message --- FYI: The status of the wmaker source package in Debian's testing distribution has changed. Previous version: 0.95.4-2 Current version: 0.95.5-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. --- End Message ---
Re: [PATCH] Basic WINGs theming
hes and he is fed up. He has a 40-patch series that is not applied yet, and I'm not sure what to do. -- 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
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" escribió: >> >>> On Sat, 9 Nov 2013 at 21:55:16 +, Rodolfo García Peñas (kix) >>> wrote: >>>> >>>> "Carlos R. Mafra" 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.
New fork? Was: Re: [PATCH] Basic WINGs theming
Thanks again for your reply.
As you can see in their last mail, about the idea of include more commiters
("Bad idea"), things doesn't change too much. For me is unacceptable.
If more people thinks that is good moment to make a fork and create a new repo
with more than one commiter, more democratic, I will collaborate in the new
fork.
Cheers,
kix
On Sat, 09 Nov 2013, SJS escribió:
> (Apologies to John, once again. I need a round tuit...)
>
> begin quoting Rodolfo Garc??a Pe??as (kix) as of Sat, Nov 09, 2013 at
> 05:13:17PM +:
> [chop]
> >> 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?
>
> In an open-source world? Not really. The code is all there, if the
> majority really find the curator to be unacceptable, they'll fork.
> If the fork attempt fails, the majority isn't as major as they thought,
> or the curator wasn't as off-base as was believed.
>
> So there isn't any tyranny of a curator, as if the majority back the curator,
> it's not a tyranny, and if they don't, they follow the fork, and again, no
> tyranny.
>
> The more interesting thing to discuss is: "What problem do you have
> with the aesthetic 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.
>
> How big is the team for *BSDs or the Linux kernel, compared to the
> contributing base?
>
> I don't think WindowMaker has enough players to handle having a
> small team of curators, without crippling development.
>
> >> 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.
>
> It's also the fundamental argument for security: your systems, your rules.
> Not all lessons learned as children are bad. :)
>
> > There are a lot of project and forks for this reason. Many
> > applications to do the same. Is bad be a little bit open?
>
> It is not quite a bit open? Anyone can suggest a patch. Chances are, changes
> will make it into the codebase.
>
> The problem does not appear to be openness, but with standards and cadence;
> not all changes are accepted at first acceptance, and may require a couple of
> iterations before they're deemed be be 'up to snuff' and applied, and the time
> between the submission and the ultimate acceptance can be slightly longer than
> some people wish for.
>
> I have never seen a patch rejected without a reason, and the reasons that I
> have read have always seem, well, reasonable. Voting to overrule a reasonable
> objection in order to speed things up strikes me as unwise.
>
> Patience is not well served by the hammer of democracy.
>
> [chop]
> >>> 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?
>
> I don't agree with your perspective.
>
> Do you want a curator or an integrator? A curator has opinions and
> sensibilities based on experience and talent, and a big part of the
> job is applying those. You trust the curator to do the Right Thing.
>
> An integrator is just someone who has the task of orderly incorporating
> changes and somehow making it work well enough to gain acceptance.
>
> If you want a curator, delegate the responsibility and either abide
> by the decisions they make, or find a new curator.
>
> If you want an integrator, pay them a salary.
>
> I do not see the trust misplaced. I *do* have a problem of talking about
> a curator being _forced_ (in theory) to accept a change they object to,
> rather than having a discussion that teases out and clarifies the actual
> issues, so they can be addressed in the open, and either the curator's
> mind changed by discussion, or the proposed change modified to address
> the objections.
>
> Committees make poor engineering decisions.
>
> --
> SJS
>
>
> --
> 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: [PATCH] Basic WINGs theming
"Carlos R. Mafra" escribió: On Sat, 9 Nov 2013 at 19:19:21 +0000, 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
Yaroslav Fedevych escribió: On Nov 9, 2013, at 6:24 PM, Carlos R. Mafra 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" escribió: On Sat, 9 Nov 2013 at 17:13:17 +0000, 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
SJS 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
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.
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: Alt+Tab and mouse
Nerijus Baliunas escribió: Hello, when Alt+Tabbing, is it possible to ignore mouse? Sometimes mouse cursor is in the center of the screen, and Alt+Tab ends not where I intended to. You move the mouse? (perhaps only a bit?) and then wmaker detects a mouse_move event or the problem happends without moving the mouse? Regards, kix Regards, Nerijus -- 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
On Mon, 04 Nov 2013, Torrance, Douglas escribió: > > > From: Rodolfo García Peñas [k...@kix.es] > > Only one comment about them, probably the theme variable should be included > > in the global variable, not in scr. > > Thanks, Kix! > > Which global variable are we talking about? I know Window Maker has > w_global, but I'm not seeing one in WINGs. I may be completely wrong, but it > seems like we wouldn't be able to assume WINGs has access to Window Maker > variables, e.g., running wdm or, for whatever reason, running WPrefs in Unity > or something. My mistake. Your code is ok :-) kix > I chose to put the theme in the WMScreen since everything else seemed to be > put there (the original colors, fonts, etc.). Also, Window Maker has all its > theme information in the WScreen. > > Doug > > -- > 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 full screen windows
On Mon, 04 Nov 2013, Amadeusz Sławiński escribió: > Hey, > > Another problem, this time with usability. > > Start xterm and firefox, enter fullscreen (F11) in firefox, > now win-tab (or alt-tab, whatever you use to change windows ;) > and select other window. > Notice that firefox still stays shown on top, while other window has > focus. Also if one has bind for windowmenu it gets activated but is not > shown above fullscreened window. > > Now I'm not sure what the correct solution would be. > > * disable some shortcuts when focused windows is fullscreen IMO is better hold the same behavior always. Change the behavior could disturb the user. > * don't make fullscreen window special with relation to stacking, just > raise it on top when fullscreening > > I would prefer second solution, however I would like to have some > confirmation before writing patch. +1 for second solution. Cheers, kix > Amadeusz Sławiński > > > -- > 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: [PATCH] Basic WINGs theming
On Mon, 04 Nov 2013, Torrance, Douglas escribió: > > I'm not sure about whether this is a good idea. The default look is classic > > and > > I'd guess few people would ever want to change how wmaker looks like. > > For the classic look, a user just has to not touch the WMGLOBAL file. It's > still the default. > > As the writer of the patch, I'm certainly one of the people who would like to > change the look. :) The window manager itself is extremely customizable. I > think it would be nice if the corresponding widgets were as well. (It's > still nowhere near as powerful. There's no gradient or pixmap support, just > solid colors.) > > Doug +1 for this patch. I think is good idea the people have the option to change things. I have a bug in the debian BTS about problems with colors, see [1]. If the user can change things, probably this wishlist bugs could be solved. Are only about 70 lines more only, moreover, the patches are clearer than the original code, for example: - tPtr->lightGray = WMCreateRGBColor(scr, 0xd9d9, 0xd9d9, 0xd9d9, False); - tPtr->tabColor = WMCreateRGBColor(scr, 0x8420, 0x8420, 0x8420, False); + tPtr->lightGray = scr->theme->unselectedTabHighlight; + tPtr->tabColor = scr->theme->unselectedTabBackground; Only one comment about them, probably the theme variable should be included in the global variable, not in scr. Thanks for your patches Doug! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=21888 -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/4] wrlib: Use a Conditional for GIF in the makefile instead of #if in source
On Sun, 03 Nov 2013, Christophe escribió: > From: Christophe CURIS > > > > Hi Christophe, > > > > good idea, probably we can use it with other wrlib image types (tiff, jpeg, > > ppm,...). > > > > Nice patches. > > kix > > Are you suggesting... something like this? Errrmmm, yes :-) xpm probably is a little bit different. If xpm.c is not used, then nxpm.c is used, and viceversa. xpm is mandatory. Thanks Christophe. kix > Regards, > Christophe. > > > configure.ac | 147 --- > m4/wm_imgfmt_check.m4 | 169 > ++ > wrlib/Makefile.am | 17 +++-- > wrlib/jpeg.c | 4 -- > wrlib/png.c | 4 -- > wrlib/tiff.c | 4 -- > 6 files changed, 220 insertions(+), 125 deletions(-) > > -- > 1.8.4.rc3 > > > -- > 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: [PATCH 3/4] wrlib: Use a Conditional for GIF in the makefile instead of #if in source
Hi Christophe, good idea, probably we can use it with other wrlib image types (tiff, jpeg, ppm,...). Nice patches. kix On Sun, 03 Nov 2013, Christophe escribió: > From: Christophe CURIS > > The use of the conditionals provided by autotools provides a better result > as they avoid unnecessary compilation. > > Signed-off-by: Christophe CURIS > --- > m4/wm_imgfmt_check.m4 | 3 ++- > wrlib/Makefile.am | 6 -- > wrlib/gif.c | 4 > 3 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/m4/wm_imgfmt_check.m4 b/m4/wm_imgfmt_check.m4 > index 4c44b7a..ef3f478 100644 > --- a/m4/wm_imgfmt_check.m4 > +++ b/m4/wm_imgfmt_check.m4 > @@ -64,7 +64,8 @@ AS_IF([test "x$enable_gif" = "xno"], > AC_DEFINE_UNQUOTED([USE_GIF], > [1], > [defined when valid GIF library with header was found])]) > -])dnl > +]) > +AM_CONDITIONAL([USE_GIF], [test "x$enable_gif" != "xno"])dnl > ]) dnl AC_DEFUN > > > diff --git a/wrlib/Makefile.am b/wrlib/Makefile.am > index c98a60f..dc379a1 100644 > --- a/wrlib/Makefile.am > +++ b/wrlib/Makefile.am > @@ -40,9 +40,11 @@ libwraster_la_SOURCES =\ > ppm.c \ > png.c \ > jpeg.c \ > - tiff.c \ > - gif.c > + tiff.c > > +if USE_GIF > +libwraster_la_SOURCES += gif.c > +endif > > LTCOMPILE2=`echo $(LTCOMPILE) | sed -e s/-fomit-frame-pointer//` > COMPILE2=`echo $(COMPILE) | sed -e s/-fomit-frame-pointer//` > diff --git a/wrlib/gif.c b/wrlib/gif.c > index ebd8729..e1b1a73 100644 > --- a/wrlib/gif.c > +++ b/wrlib/gif.c > @@ -22,8 +22,6 @@ > > #include > > -#ifdef USE_GIF > - > #include > #include > #include > @@ -209,5 +207,3 @@ RImage *RLoadGIF(const char *file, int index) > > return image; > } > - > -#endif /* USE_GIF */ > -- > 1.8.4.rc3 > > > -- > 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: Fonts, dialogs, etc
On Sat, 02 Nov 2013, Carlos R. Mafra escribió: > On Sat, 2 Nov 2013 at 0:30:19 +, Torrance, Douglas wrote: > > > > Finally, I noticed that kix had submitted some patches related to the > > dialogs back in May. It doesn't look like they ever got applied, and I > > was wondering if this was just an oversight. Here's a link: > > http://lists.windowmaker.org/dev/msg05004.html > > Thanks for pointing it out. I think they escaped my attention somehow, > my bad. The patches are OK, but they no longer apply. Thanks Douglas! Carlos has a mail filter, and send my mail to "Spam" :-P I sent the patches again. kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Icon behavior with multiple screens
Hi, I am running windowmaker with two screens. Main screen is left, and the dock is in the second screen. The icon behavior is odd. When I launch an application, the appicon is painted in one screen (left), but if I minimize the application, the icon goes to the other (second). I have similar issue with applications. When I open an application using the menu, the application window is painted in the same screen where the menu is. That is nice because I can control where the window should be painted (yes, the icon always goes to one screen, in my case, left). But when I use the dock, the window is painted where the dock is, no in the screen with more left space. For example, in my configuration, with the dock in the second screen, if I have the screen full of windows, and I run an xterm using the dock, the window continues in the same window. Perhaps, the rigth behavior should be: 1. appicon should be painted in the same screen where the window was launched. 2. appicon could be moved to the screen where the window is. 3. application launched using dock should be position in both screens, like if we are using one big screen. About the option three, and about questions about multiple docks in previous mails, perhaps make sense the application is launched where the dock is, but I don't know how setup multiple docks, one per screen. Any help? If we cannot use multiple docks, probably we should check the code to use only one dock. Best regards, kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: wdm
On Mon, 23 Sep 2013, Alexey I. Froloff escribió: > On Sun, Sep 22, 2013 at 02:14:42PM +0200, Rodolfo García Peñas wrote: > > I will adopt the wdm package for Debian. I saw that you have a > > fork in github and the upstream (email, homepage) doesn't exist > > anymore. > > Do you have more info? > Well, I am the upstream now ;-) See README.voins. > > Tag "wdm-1.28" is the last release made by Alexey Voinov. In > "master" branch I have some work-in-progress cleanups and > improvements. > > However, current code is a total mess. It was started as fork of > XDM somewhere in 2002... Now I am thinking about dropping > current code completely, take lxdm/lightdm/whatever sources and > just rewrite the UI using WINGs. Hi again, IMO the current code in your repo is not good for a stable environment. Perhaps could be a good idea create a new branch, based in the original code, and then apply "stable" patches. We can "migrate" patches from the current new branch to this new stable branch and I could send the patches included in Debian. Then, we can continue with a stable wdm, and I can use it to make the Debian package. What do you think? Best regards, kix. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ 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 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: WindowMaker: lost maximized status
Iain Patterson 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.
