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 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: 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: 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: [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.
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: 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: 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.
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.
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: 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.
Re: WindowMaker: lost maximized status
Cc Sergey, I am not sure if he is in the mail list. Thanks Iain. Cheers, kix Iain Patterson escribió: Quoth Sergey Popov, - start gvim gvim --servername qwe .gvimrc - maximize (vertical, horizontal or full) created Gvim window. Window menu has "Unmaximize" item. - open another (or same) file to the same Gvim window gvim --servername qwe --remote-silent .gvimrc - now winsow menu has "Maximize" - Gvim window cannot be unmaximized --> maximized status is lost. gvim generates a ConfigureRequest event. We handle it in the aptly-named handleConfigureRequest() which in turn calls wClientConfigure(). wClientConfigure() calculates the new geometry and saves the old geometry in the wwin->old_geometry struct, after clearing the maximized flag if the requested width or height is different from the old geometry width/height and calling wWindowConfigure(). The clearing of the maximized flag was done as part of commit e4fcd515fe8089a547f23ce7d0089607b35d44e2 to fix a bug with moving a maximized window. I don't think that commit is the problem. We might be able to check for the new geometry being different from the current (not "old" ie pre-maximization) geometry and skip the steps above if it's the same. The patch would be easy to write but it will need some testing to check for unwanted side effects. I'll have a look into 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.
Fwd: WindowMaker: lost maximized status
Hi, some help with this bug? Thanks a lot, Best regards, kix - Mensaje reenviado de Sergey Popov - Fecha: Thu, 24 Oct 2013 08:56:28 +0200 De: Sergey Popov Asunto: Re: WindowMaker: lost maximized status Para: Rodolfo kix Garcia Hi, The problem still exists in 0.95.5. To reproduce: - start gvim gvim --servername qwe .gvimrc - maximize (vertical, horizontal or full) created Gvim window. Window menu has "Unmaximize" item. - open another (or same) file to the same Gvim window gvim --servername qwe --remote-silent .gvimrc - now winsow menu has "Maximize" - Gvim window cannot be unmaximized --> maximized status is lost. 2012/5/6 Sergey Popov Hi, The patch does not solve the problem. Regards, Sergey 2012/5/6 Rodolfo kix Garcia El 22/04/2012 14:10, Sergey Popov escribió: Hi, Additional info: if maximized window is shaded, the problem does not occur. It seems, the problem in client.c (version 0.95.2) line 221-263: old_geometry is updated to "maximized" values. Sergey 2012/3/9 Sergey Popov mailto:psvor...@gmail.com>> Hi, Correct scenario. If "UnMaximize" restores normal window size? I open gvim (e.g., 600x400 pixels) -> maximize it vertically (now 600x1024) -> run second command (remote-silent) -> try unmaximize gvim ---> it seems, the state is changed from maximized to normal, but window size stays 600x1024 (like maximized vertically). For maximizing I use keybinding, defined in WPrefs. Regards, Sergey 2012/3/8 Rodolfo kix Garcia mailto:k...@kix.es>> On 26/02/12 14:43, Sergey Popov wrote: > Hi, > > The old bug in WindowMaker (0.95.2). > > 0. Before reporting this bug I already: > [ x] read the NEWS, README and INSTALL files > [ x] read the list of already known bugs in the BUGS file > [ x] downloaded and tried the latest version of WindowMaker > > 1. What happened: > [ ] could not compile > [ ] crashed > [ ] configuration option does not work > [x ] weird behaviour > [ ] cosmetic > [ ] some problem with WPrefs > [ ] others: .. > . > > 2. Detailed description of what happened: > Maximized status of window is lost. > > 3. How to reproduce the bug, if known: > - Start gvim > gvim --servername qwe .gvimrc > - Maximize (vertical, horizontal or full) created Gvim window > - Open another (or same) file to the same Gvim window > g --servername qwe --remote-silent .gvimrc > - Try to restore Gvim window --> maximized status is lost. > > 4. Configure time options you specified: > [ ] --enable-kanji > [ ] --disable-shape > [ ] --enable-single-icon > [ ] --enable-modelock > [x ] Others: run configure without parametes (all defaults) > > 5. Changes to the src/wconfig.h file: > > 6. The error occured during: > [ ] configuration > [ ] compilation > [ ] startup > [x ] use > > 7. Changes made to the configuration files, if the error ocurred during use: > > 8. Error messages output: > > 9. Fix, if known: > I don't have enough time to locate it in code > > 10. Other Notes: > This is old bug. I saw him at 0.91 or 0.92 > > My e-mail: psvor...@gmail.com <mailto:psvor...@gmail.com> <mailto:psvor...@gmail.com <mailto:psvor...@gmail.com>> > OS: Linux 3.0.0-1-686-pae #1 SMP Sat Aug 27 16:41:03 UTC 2011 i686 GNU/Linux > Distribution: Debian, several versions > Window Maker 0.95.2 > > Best regards, > Sergey Popov Sorry, I don't understand :-( I ran in a xterm: kix@osaka:~$ gvim --servername qwe .gvimrc Right click on the window title, maximize. alt+tab to return to the xterm OR mimimize the the window. kix@osaka:~$ gvim --servername qwe --remote-silent .gvimrc I have only one gvim window (the first). If the window was minimized, the command re-maximize it. If I make right click, I see "UnMaximize" option (the window is still maximized). I'm doing something wrong? Cheers, kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ Hi, did you see the patch sent some days ago to the mail list? Topic was "Patch: Make maximize hotk
Re: [PATCH 0/6] A few bug fixes and one minor improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/10/2013 22:36, Daniel Déchelotte wrote: > On Sat, 19 Oct 2013 Rodolfo García Peñas wrote: > >> - Push and hold Alt key - Click on the docked app - Detach it >> from the Clip (continue holding the Alt key and the mouse >> button) >> >> Now, if you try to attach it again, you can't! You must release >> the Alt key and then push it again to attach the icon again >> (don't release the mouse button). >> >> With the old behavior, when you hold the Alt key and detach the >> icon, then, the shadow is painted and the icon is ready to be >> attached to the Clip or the Dock. > > Alright, so we are talking of the same thing, but disagreeing on > what factually happened in the old behavior :). I maintain that, in > the old Nice :-) > > If the mouse button is released while Alt is pressed (and after > the mouse is moved a bit :-/), you are in step 3 above: no docking. > If Alt is no longer pressed, step 5, docking is possible. > > This is what I observed in wmaker-0.95.1 (Jan 2013). > > Do you repro the "I can move an appicon from a dock to another with > Alt pressed" behavior with that version? Ok, forget all. What should be the rigth behavior? 1. Alt button always pressed detatch and attach the icon? 2. Alt button pressed detach the icon + released attach it again? I don't know if the wmaker-0.95.1 (Jan 2013) version was option 1 or option 2. I think the original behavior was option 1, but I am not sure now. But... what we want now? Thanks Daniel! kix > -- Daniel > - -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSY9haAAoJEHsfVJByt0kjhjkP/1Zf8vyE6TqYL5kw1X0EzDwy HIOvrVX8rW6LnMWXDUc0RLwaT+w5Lyfzocgmdxq0/i5Zz4Z+lWh3ZdSqL0AFkdcI 3LiFO/ya7y/fGc8AMS7Q8Juay3Pzx5fOs0LxrFeK9lBB7zhr+HVEis1LIiGHhkb+ E3Fz2L2Rg59B79B43zHOmJ4Ipk59BIFeaNtAfQ72Qp4tV1cg5awKyougbaQHxb5j ePCivi+IVQEk7vHmEOBAfccWb999KJEqNCP/h5B42OPP+OULToo1SBViRTjlRz+o NtWlEC1JAipeZ28yH0BgPtJxeQCrQK62FEKeFRbBPUfyn6nLMBXqQ65YYX11Iaru Bv7+l3DJoJfLoYXz+MsmKvwYduhQFD32Y0gk+7tn2SGdXlIqhw7D4lVlktYlozhr cmk1j15r5b7eAv4Hx29Dxw+wSi1h+FsGP5dhuG7viaOwtMulygBAVEQ3x1Y8P/Ty q1bq8cMBn3ZoEdaOh5THBRe+CcMPTcdxavUeNvEEZli4JD78yohECZeTBkDiNqfD g4rFQM+WCQmR0Ux4ZjqTda3st32RjBFBpIaj2/q/xhAg2ZpYp3/8f2m2PSLVSX62 R5ZcbHB1eUraqqtbf2Pj2OBsYnOQ2/gwP3JkYxWzfWSkhVwTOqDjXGp3+CFIftR4 dgIRrBuLZROLLKGKNM7K =YAuq -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : [PATCH 00/38] Help needed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was thinking about this... Probably is better that more people try to solve the XRandR problem. New ideas, new points of view. Perhaps we should think about create the object, and then "add" the screens to it. If we plug a new monitor, we add a new screen to the objects, if we unplug the monitor, we remove the screen. I don't know. I will stop here some days. Ideas are welcome. Cheers, kix - -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSY9ZUAAoJEHsfVJByt0kj6TQP/0vD3C4D0V/iZG5YdJfrhwb7 Q4Bx1LKey1EGV0RmR9puO1OF9dXuIVSZXLDw2lkv/1a9YrLmX4uixijDCZxdGcYs dSYfVdnGbtToVYod9DLE2XrHveEyqJwc9mxe54mAVWHCfxsESCQRML541AK012uT KCNIGUn6AWlQQPIDvRjis2x0MkL2dhAuJoUXNTPwEExEe92tpOtmXH9MBk0XCK4I CZ0jgKQt6c7YgvJweWn1/oj7SKbOU7Zsa9Vm89YSeJcLLapRT15BPLj7T4d82fOZ s28Pzav3QVS5DMg1oMEIFMy1QwPIe9nFWmcfEKDC1O+lz4i/XVX+8nL/LjYnODiR x0NDT6Pm9hiqtEVXQpuyh+4Gjy2cZF6YUXSE5/Q4U5z/lEFzA8DIRVYjuvWUkpLa zfagrhP8tRNJe7jfA3uly4UtQh6W0fzi0l5+bMBoumqnhLE66USMoHnTt78g7iW7 6kO9kYT/ikL0jaPGrWsDDcYUEU+hrIa19e8jqbTOuMPv9B0cIndg/d0hSlcDCHrA /cdPJJ6g8Wkt5LYjDRxmy1MXK3pTu2w5/MxwQP8UXuMwJM/RbunQ29x56tW0oqBh ionfy8ptmTbWzizVMWIZl4alq1NjONIZowTCkbJlHd0Jqgq7krly71iPlQPu/H+H jZb1Ub4LsfqRaovZ/DBA =xxsJ -END PGP SIGNATURE- -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Removed unused WScreen argument
Sorry Christophe, I write an email about that, but I had problems with the server. I am using my phone to connect :-/ The mail had the explanation about that. It was about the problem about the warning is only for variables in the function, not in the function arguments. Regards, kix Christophe escribió: From: Christophe CURIS Hi Rodolfo, That's a good catche, and here are a few more... Regards, Christophe. src/appicon.c | 2 +- src/defaults.c | 2 +- src/defaults.h | 4 ++-- src/dock.c | 12 ++-- src/dock.h | 6 +++--- src/dockedapp.c | 2 +- src/pixmap.c| 2 +- src/pixmap.h| 2 +- src/screen.c| 6 +++--- src/wdefaults.c | 4 ++-- src/window.c| 4 ++-- src/workspace.c | 4 ++-- src/workspace.h | 2 +- 13 files changed, 26 insertions(+), 26 deletions(-) -- 1.8.4.rc3 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/4] probably the last batch on global variables
Hi Christophe, did you check if some variables (like WScreen) in the function definition are not longer used in the functions of these patches? Cheers, kix Christophe escribió: From: Christophe CURIS Hello, It looks like this should be the last changes on global variables that were declared in not so great places. Regards, Christophe. Christophe CURIS (4): wmaker: Moved variable ValidModMask into the global namespace wmaker: Moved global domain definition to the global namespace wmaker: Moved definition of global variable 'wKeyBindings' to header Added compilation check for dangerous use of 'extern' keyword configure.ac | 5 + src/WindowMaker.h | 16 ++-- src/appicon.c | 7 ++- src/cycling.c | 4 +--- src/defaults.c| 53 - src/dialog.c | 2 -- src/event.c | 4 +--- src/keybind.h | 6 ++ src/main.c| 8 +--- src/rootmenu.c| 13 ++--- src/screen.c | 7 +-- src/startup.c | 26 ++ src/wdefaults.c | 35 --- src/window.c | 14 ++ src/winmenu.c | 3 --- src/winspector.c | 4 +--- src/workspace.c | 1 - 17 files changed, 94 insertions(+), 114 deletions(-) -- 1.8.4.rc3 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 0/6] A few bug fixes and one minor improvement
Hi Daniel, the behavior is not the same than before. If we have the clip and the dock, and I move the icon without Alt key, using the icon border, I can move the icon from the clip to the dock, with the shadow,... But, If I move the icon using the Alt key, I can press on the icon, detach from the Dock/Clip but when I move the icon near the Dock/Clip, the icon cannot be attached and the shadow is not painted. I need to release the Alt key, and push it again. Is possible to do it without release the alt key? Thanks kix. yo@free.fr escribió: From: Daniel Déchelotte The first patch fixes the bug recently discussed in the thread "IMPORTANT BUG: Unable to attach dockapps to Clip/Dock". Then 3 fixes, one for a crashing bug. Then a minor improvement when removing a drawer with a single appicon, and removing some dead code. Daniel Déchelotte (6): When moving an undocked appicon (or applet), allow it to be docked even if Alt is still pressed BF: prevents crash when toggling auto-attract on a drawer with clip disabled BF: correctly initialize the drawer tile when the dock is on the left side BF for stacking level bug when creating a drawer in a keep-on-top dock When removing a drawer containing a single appicon, the latter is docked where the drawer was, instead of being totally undocked. Remove dead code for a confirmation dialog that we'll probably never want to show src/appicon.c |2 +- src/dock.c| 68 + src/screen.c | 11 +- 3 files changed, 41 insertions(+), 40 deletions(-) -- 1.7.10.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Compiler food.
Ok, no problem :-) Done.
"Carlos R. Mafra" escribió:
On Thu, 10 Oct 2013 at 0:34:36 +0200, Rodolfo García Peñas (kix) wrote:
From: "Rodolfo García Peñas (kix)"
This patch set the variable aicon to NULL, to avoid compiler warnings.
This patch also adds some code style.
---
src/dock.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/dock.c b/src/dock.c
index 1e0405c..cb92555 100644
--- a/src/dock.c
+++ b/src/dock.c
@@ -4342,7 +4342,7 @@ static void drawerDestroy(WDock *drawer)
{
WScreen *scr;
int i;
- WAppIcon *aicon;
+ WAppIcon *aicon = NULL;
WMArray *icons;
if (drawer == NULL)
@@ -4353,21 +4353,20 @@ static void drawerDestroy(WDock *drawer)
/* Note regarding menus: we can't delete any dock/clip/drawer
menu, because
* that would (attempt to) wfree some memory in gettext library (see
menu
* entries that have several "versions", such like "Hide" and
"Unhide"). */
-
wDefaultPurgeInfo(scr, drawer->icon_array[0]->wm_instance,
drawer->icon_array[0]->wm_class);
+
if (drawer->icon_count == 2) {
- // Drawer contains a single appicon: dock it where the drawer
was
- for (i = 1; i < drawer->max_icons; i++) {
+ /* Drawer contains a single appicon: dock it where the drawer
was */
+ for (i = 1; i < drawer->max_icons; i++)
if ((aicon = drawer->icon_array[i]))
break;
- }
+
I wouldn't remove the brackets in the last 'for' loop though. This smells
like trouble in the future.
--
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.
Wrong behavior
Hi, if we have a dock, and multiple desktops, If I hold the Alt key and then make double click on a docked icon, wmaker switch the workspace to N-1. If I hold the Alt key and then make double click in a running dockapp (wmclock,...), wmaker changes the workspace to "1" :-/ This is ok? Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: no [PATCH 19/19] Removed unused keymove_tick variable
Christophe escribió: Hello, Unfortunately my mail provider is rejecting patch 19 of the series, considering it as spam for reasons I fail to understand. Hi Christophe, your work is awesome. I will try to check it ASAP (but I have a lot of work). You can try with gmail or other web mail that you can change the sender address. Regards, kix As it is just plain patch 6/6 as submitted by Rodolfo, and it does not look like to be a potential source of conflict, I propose to use the patch he submitted. Regards, Christophe. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
New debian version 0.95.5-1
Hi, the wmaker package version 0.95.5-1 is now available at debian unstable. The package took some time extra because the library libutil3 is new. Regards, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: IMPORTANT BUG: Unable to attach dockapps to Clip/Dock
Hi Daniel, because I reported the bug, probably is better I explain it. First, I always moved the icons using Alt+Button Click, and I never used Click on the corner with docked apps, so for me was "important", because the problem breaks my normal behavior. Daniel Déchelotte escribió: Carlos wrote: On Sun, 29 Sep 2013 at 2:06:43 +0200, Rodolfo García Peñas wrote: > The right behaviour is: when I move the docked application, I press > Alt and click in the application. It's related to pressing Alt. I usually move the icons by clicking in their corner and dragging. Now if I move them with Alt pressed I can reproduce the behavior. OK, tell me if I understand the bug correctly. Normally, to dock an application, you drag its undocked appicon to the dock (no Alt pressed for now). Then, to undock it, you drag it with Alt pressed. *Before* commit 9fae35fbc, when dragging an undocked appicon, you could press Alt and still dock the appicon. *After* the commit, if you press Alt while moving an undocked appicon, it won't dock. Yes, exactly. Before the commit, when I move the icon with Alt+ pressed, it can't be docked (and the shadow is not drawed). When the icon is removed (with Alt+), the icon is removed, but, the shadow is not drawed. If your bug is about the difference in behavior before and after the commit, well, at least it's "by design" (admittedly, my design, we can always discuss). Cf. the commit comment: [...] Behaves essentially the same, only a bit more consistently. Known differences: 1. An AppIcon will now always end up undocked if moved while Mod1 is pressed. [...] I called the new behavior "more consistent" because it's summarized as "moving an appicon without Mod1 (Alt) is to move and dock, moving it with Mod1 pressed is to move without docking, always". Ok, we can discuss it, but some things: - Docked applications (appdock) and applications icons are different, because I cannot click on the docked application to drag it (because the click is used by the application). - In docked apps, is easy click with Alt than without it in the corner. That is a problem for users with visual problems. - We can move things using Alt+Click, for example we can click in the center of a xterm (not in the titlebar) and move it. - When you move the docked app between Clip and Dock, the behavior is "rare". First, you click on Alt+ and start to move it, but you need leave the Alt key to dock it. The old behavior is better IMO, because you can do it without leave the Alt key. Is the bug you reported about the above difference of behavior? Yes. -- Daniel Thanks Daniel, Rodolfo. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: annoying multi-screen issue
Paul Harris escribió: Hi guys, I have trouble with multiple monitors, to ensure I don't get stuck without any screens, I use nvidia-settings to change my resolution. But, Windowmaker doesn't notice the change in screen layout. Instead, it seems I have to always use the menu to restart wmaker. Is this something that could be fixed in the future? Yes. There's a solution for everything but death (and I am trying a patch ;-) ). Cheers, kix cheers, Paul Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Replace and be replaced
Yaroslav Fedevych escribió: On 29 sie 2013, at 11:37, Carlos R. Mafra wrote: On Thu, 29 Aug 2013 at 10:32:40 +0100, Iain Patterson wrote: Quoth I, This patch allows wmaker to replace existing window managers with the --replace flag, like xfwm4 and metacity can. It also allows those window managers (or another wmaker) to replace wmaker in the same way. Any interest in this kind of stuff? I don't know if wmaker needs that stuff. I feel it's too much code for a possible minimal gain and I'd prefer to keep things simple. But at least it would be on par with almost every other window manager under the sun. Think interoperability, compatibility... I think like Carlos about wmaker should be simple. But in this case, IMO the window managers should do a minimum amount of things to be "standard", like probably this. If other window managers can replace others, and is a common feature, probably we should implement it... and is already done, so use it. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 4/4] Removed context argument in jpeg files
"Carlos R. Mafra" escribió: On Fri, 23 Aug 2013 at 1:34:56 +0200, Rodolfo García Peñas wrote: Carlos, the patches are not in the git yet, do you have comments/doubts? Sorry for the delay. They will be pushed to the #next repository after the release of wmaker-0.95.5 in the next days. No problem. Summer, vacations,... About the idea of push to #next is perfect. I will send a lot of patches the next months and I think is better push them on #next and test them some time. I am testing patches here, without problems, but I will send the patches grouping them, to make the things easier. The groups (now) are: 1.- New struct with workspace info [Done] 2.- Split icon creation and icon paint/mapping for icons (in wrlib). [Done] 3.- Split wcore creation and wcore paint/mapping (in scr). [Done] 4.- Unify Drawers/Clip/Docks in the same struct. Create functions for paint / draw them. [Working]. 5.- XRandR support. We need that create and paint/mapping/recover were splitted first (previous steps). [Old patches, waiting]. I would like to create all the stuff and then send the patches, to avoid make patches of patches. Probably I will send only patches about "code style" and bugs. I am rebasing and rebasing patches to send these patches first (it is a bit boring for me, but is good for us). If after all the work it not make much sense then I won't send nothing, except the code clean and bugs. Only one thing. I didn't test it, but probably we can remove the wrlib/nxpm.c file, because the "Normalized XPM" probably won't work as expected. I will appreciate if you can test it (using the flag "USE_XPM" define). Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Clips and Dock
Hi Daniel, thanks a lot for your comments. I will review my local repo and will change some things. Cheers, kix Daniel Déchelotte escribió: Hi kix, When you have two monitors, you basically have two options. The most popular one nowadays is to merge the two screens into a wide one with xrandr (earlier it was with Xinerama, or TwinView, or BigDesktop, or whatnot). Then you really have one screen (in X.org sense), which is quite possibly not rectangular. WM manages that single screen and displays a single dock, at the left of the leftmost head (monitor) or at the right of the rightmost one. The other option is to keep the two screens separate. As I understand, windows can't extend from one screen to another, they can't be moved across screens. There is a single X server, the user logs in once and he gets two screens, but those are totally independent from each other. A single instance of WM manages both, and each has its own dock. I've never run that setup; in fact, I wouldn't even know how to force X to keep the two screens separate to test my changes in that condition. But I think that explains the "multiple screen" code in WM. HTH, -- Daniel PS: the excerpt below is from startup.c ;-) - Mail original - Hi, only one stu^H^H^H simple question. There are one Clip per Workspace, but... How many Docks are in wmaker? One? Is the same for all workspaces? Probably seems an s^H simple question, but I am working on workspaces these days and yesterday I had this question. See this: screen.c: 722 if (!wPreferences.flags.nodock && wScreen[j]->dock) 723 wScreen[j]->last_dock = wScreen[j]->dock; This code show that there are one Dock per Screen. IMO, it makes no sense. I have code here with only one Dock. I am testing. Cheers. kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 4/4] Removed context argument in jpeg files
BALATON Zoltan escribió: On Fri, 23 Aug 2013, Rodolfo García Peñas wrote: - RLoadImage(file): Load the image, and render it if the RContext is not needed. - RDrawImage(RContext, RImage): Draw the image on the WScreen. This function depends on the WScreen. With this change, we can create items (Menu, Dock, Clip,...) that are screen independent. Then, we can draw them on the WScreen when needed. If the WScreen change (for example, with XRandR), we only need repaint them (using RDrawImage). What is the advantage of this change? Would this move some operations that are now done when the image is loaded only once to drawing the image which can be done frequently? Does this lead to less efficient operation (by eliminating images that are now cached for each screen)? (You could argue that current systems are fast enough but doing unnecessary work is still unnecessary, so shuold not be done if not needed.) Is the reason for this change purely esthetic (i.e. some code would look better)? If so, is there another way to make code look better (like using macros or new functions to hide ugly parts)? These are just some questions without knowing anything about your proposed changes, so maybe I'm completely misunderstood this... Hi! We are talking about different things. A little example: - Think about a wmaker screen, only with the Dock icon. The Dock icon uses a xpm icon. When you run wmaker, it creates: 1st: The WScreen (the screen) interacting with X11 server. 2nd: Call to create the Dock Icon. To create the Dock icon, the dock-create function calls RLoadImage to create the XPM image. The image is created, using the WScreen variable. In this example, the XPM image depends on the WScreen. This is the current behaviour. What's happend if the user changes the Display/Screen? wmaker must restart, reload files again, and re-do all again. With the new code: 1st: We create the Dock icon. To create the Dock icon, we use RLoadImage to read the XPM from disk. The image is not yet created (fully, only the screen independent work). We don't need the WScreen variable. The Dock struct is created in memory, not painted! 2nd: We create the workspace and the WScreen. Then, we need paint the Dock. Then, we call RDrawImage. If we add, remove or change the display/screen, no problem. We only need do the 2nd part of the code. We don't need re-read the images from disk. kix. Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Help with libwraster
"Rodolfo García Peñas (kix)" escribió:
Hi,
Is possible remove the context argument in the RLoad functions for
xpm, PNG and jpeg ?
The context variable contains the specific WScreen, and is a problem
for example with XRandR when switching the screen. IMO, the images
should be screen independent.
I have some patches to solve these problems.
One question more (please, don't reply all together because my inbox
is full ;-) ).
The RContext struct includes the flag "optimize_for_speed". This flag
is only used in JPEG images, if is not set the jpeg image load process
includes the alpha channel, but if is set, the alpha channel is not
loaded.
To set the variable is used this code (context.c):
506 ptr = mygetenv("WRASTER_OPTIMIZE_FOR_SPEED", screen_n);
507 if (ptr) {
508 context->flags.optimize_for_speed = 1;
509 } else {
510 context->flags.optimize_for_speed = 0;
511 }
IMO this flag is old. The flag is only used in jpeg images, and with
the current processors, the alpha channel should be included always. I
have a patch to remove this flag, what do you think?
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Alt+tab crashes Windowmaker
Juan Giordana escribió: Hello, I'm using Linux mint and just built the latest Windowmaker from the git repo and it crashed when I tried to switch windows with alt+tab. - I've created 5 workspaces and added some keyboard shortcuts to my config and selected the optoin to raise the windows while switching them with alt+tab - Went to the workspace 'www' opened chromium, opera, firefox and an xterm - Quickly pressing Alt+tab crashed WindowMaker - Not so quickly behaves poorly. Regards Hi Juan, could you help us with "git bisect" to find the wrong git commit? Thanks, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH] Fixed structure declaration syntax
Christophe escribió: From: Christophe CURIS As reported by Iain Patterson, the clang compiler is (by default) strictier on having clean C syntax. A few structure definition did not comply, now they do. Signed-off-by: Christophe CURIS --- WINGs/WINGs/WINGsP.h | 12 ++-- src/geomview.c |4 ++-- 2 files changed, 8 insertions(+), 8 deletions(-) [snip] Nice work. wmaker is now more wmaker. Only one thing. Please, remember that making changes on the libraries (WINGs, libraster, ...) could impact in the applications that use these libraries. Probably are only a few, but we should remember them. Cheers. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Re : Re: Re : Re: [PATCH 06/19] wmaker: Reorganised the header 'funcs.h'
Hi
I Am not with my laptop, short answer.
I don't agree because your proposal is include all headers files in
all source files. We should include only the headers needed.
Cheers
Kix
Quoting Christophe :
- Carlos R. Mafra a écrit :
On Sun, 12 May 2013 at 13:13:45 +0200, Christophe wrote:
>
> [...]
I tend to prefer having separate header files matching their .c files.
It is simpler conceptually.
Sorry for the late answer, have been quite busy again...
Maybe it's a bit late now, as Rodolfo has started the clean-up, but
I was thinking about a methodology which could be added to the
coding style rules:
- All source files must include only 1 header
* that does not count system headers
* the idea is to avoid missing some #include, like it was the case before
* this header handles in one place the inter-dependency of headers
- All source file must define their own header, from the moment
they share more than 3 functions or a struct definition
* the arbitrary limit of 3 is here to avoid too small file which
scatter things
* uses 'WM__H' for include guards
* defines structs first, then function prototypes (with a
comment separator between the 2 sections)
- The common header does this, in *this* order:
* includes config.h from configure
* includes system headers that may be needed (types used in
headers and covers the HAVE_xxx from configure detection)
* defines anonymous structs that are needed ("typedef struct
;" without content)
* includes all the source headers (handles the right order,
makes sure nothing is missing)
* defines the prototypes for functions in the case of 3-or-less
functions from above (with appropriate separator comment with source
file name)
This is, of course, open to comments, but it provides a good base to
have things in a safe, easy-to-work-with state.
Regards,
Christophe.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Cube dock image
Hi, I did it using a snapshot and gimp. Test it please. Cheers, kix. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ <> dockcube.xcf Description: Binary data
Re: Add dock icon to wmaker
On 11/05/2013 22:00, BALATON Zoltan wrote: > On Sat, 11 May 2013, "Rodolfo García Peñas (kix)" wrote: >> is possible add that [1] icon to wmaker? I am thinking add the icon to >> the available icons in wmaker. Using it as default dock icon is other >> story. >> >> [1] http://lists.windowmaker.org/dev/msg04515.html > > I don't have that icon either that's why I was asking the same question > but I never got an answer. > > Regards, > BALATON Zoltan I sent a tweet to @crunchbang, because is a distro... and perhaps they included that file. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 06/19] wmaker: Reorganised the header 'funcs.h'
On 12/05/2013 0:24, Christophe wrote: > From: Christophe CURIS > > The functions are now grouped by source file (groups in alphabetic > order) with the traditional separation mark. This makes the file > easier to work with. > --- > src/funcs.h | 53 ++--- > 1 file changed, 38 insertions(+), 15 deletions(-) > Hi Christophe, thanks a lot for your patches. Hard work. Only one comment about this patch. The file funcs.h contains prototypes for multiple files, and funcs.c doesn't exist. IMO, is better move the prototypes to the right header file, and remove funcs.h. Probably we can apply this idea for src/keybind.h Other options (fuzzy): - Files like extend_pixmaps.h and def_pixmaps.h could be merged. - GNUstep.h and WindowMaker.h probably could be checked,... Again, thanks for your work. kix. -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Add dock icon to wmaker
Hi, is possible add that [1] icon to wmaker? I am thinking add the icon to the available icons in wmaker. Using it as default dock icon is other story. [1] http://lists.windowmaker.org/dev/msg04515.html Cheers, kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/4] wWorkspaceMenuUpdate checks current_workspace
Hi,
Carlos, don't apply these patches.
Patch 1 only: wmaker crash.
Patches 1+2: wmaker crash.
Patches 1+2+3: wmaker crash.
Patches 1+2+3+4: The workspace list is not updated when change to
workspace 1. No problem with other workspaces.
Problems 1,2,3 with my original patches worked. I need check the problem
with 4.
Saludos,
kix
On 20/04/2013 16:17, Rodolfo García Peñas (kix) wrote:
> From: "Rodolfo García Peñas (kix)"
>
> The function wWorkspaceMenuUpdate() udpates the menu entries
> using the scr->current_workspace variable. The problem is that
> variable could be NULL, so wmaker will crash.
>
> This patch include a new check to verify that scr->current_workspace
> exists before use it.
> ---
> src/workspace.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/workspace.c b/src/workspace.c
> index b4cccd0..29aab12 100644
> --- a/src/workspace.c
> +++ b/src/workspace.c
> @@ -743,7 +743,7 @@ WMenu *wWorkspaceMenuMake(WScreen * scr, Bool titled)
> return wsmenu;
> }
>
> -void wWorkspaceMenuUpdate(WScreen * scr, WMenu * menu)
> +void wWorkspaceMenuUpdate(WScreen *scr, WMenu *menu)
> {
> int i;
> long ws;
> @@ -751,7 +751,12 @@ void wWorkspaceMenuUpdate(WScreen * scr, WMenu * menu)
> WMenuEntry *entry;
> int tmp;
>
> - if (!menu)
> + /*
> + * If the scr->current_workspace doesn't exists yet
> + * is because we are starting wmaker, so we don't need
> + * the workspace menu yet
> + */
> + if (!menu || !scr->current_workspace)
> return;
>
> if (menu->entry_no < scr->workspace_count + MC_WORKSPACE1) {
>
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 1/3] Screen initialization doesn't create workspace
On 20/04/2013 16:14, Rodolfo García Peñas (kix) wrote: > From: "Rodolfo García Peñas (kix)" > > When the screen is created, it creates the initial > workspace. This workspace could not be created, because > is not used. The workspaces are created later, so we can F*ck!!%4$1~ forget this serie, I forgot 1 patch (the first) -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 2/6] Avoid create WorkspaceMenuUpdate on wmaker start
On 20/04/2013 15:33, Carlos R. Mafra wrote:
> On Sat, 20 Apr 2013 at 14:05:00 +0200, Rodolfo García Peñas (kix) wrote:
>> From: "Rodolfo García Peñas (kix)"
>>
>> This patch avoid update (create) the Workspace Menu when wmaker
>> is starting. When wmaker is starting, the scr->current_workspace
>> is NULL, so we can check it in wWorkspaceMenuUpdate() and do nothing.
>>
>> --8<--
>> @@ -751,7 +751,12 @@ void wWorkspaceMenuUpdate(WScreen * scr, WMenu * menu)
>> WMenuEntry *entry;
>> int tmp;
>>
>> - if (!menu)
>> + /*
>> +* If the scr->current_workspace doesn't exists yet
>> +* is because we are starting wmaker, so we don't need
>> +* the workspace menu yet
>> +*/
>> + if (!menu || !scr->current_workspace)
>> return;
>> --8<--
>>
>> So, now we don't need check in that function if the scr->current_workspace
>> exists:
>>
>> --8<--
>> - if (scr->current_workspace) {
>> - menu->entries[scr->current_workspace +
>> MC_WORKSPACE1]->flags.indicator_on = 1;
>> - wMenuRealize(menu);
>> - }
>> + /* Update the workspace's menu */
>> + menu->entries[scr->current_workspace +
>> MC_WORKSPACE1]->flags.indicator_on = 1;
>> + wMenuRealize(menu);
>> --8<--
>
> Wait! You just added this check in patch 1. This is a sign that your
> patches are in wrong order.
Yes,
I did that because is easier to understand. If I add only the
if (!menu || !scr->current_workspace)
is difficult know why I added it.
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 3/8] Add the application to the wapp_list
Quoting "Carlos R. Mafra" :
On Sun, 14 Apr 2013 at 23:13:28 +0200, Rodolfo García Peñas (kix) wrote:
From: "Rodolfo García Peñas (kix)"
The screen has a list of applications:
8<
kix@debian:~/src/wmaker/wmaker-crm/src$ grep wapp_list screen.h
struct WApplication *wapp_list;/* list of all aplications */
kix@debian:~/src/wmaker/wmaker-crm/src$
8<
But this variable was not set before this patch:
- Was removed in application.c
- Local variable in session.c
8<
kix@debian:~/src/wmaker/wmaker-crm/src$ grep wapp_list *.c
application.c: if (wapp == scr->wapp_list) {
application.c: scr->wapp_list = wapp->next;
session.c: WMArray *wapp_list = NULL;
session.c: wapp_list = WMCreateArray(16);
session.c:&& (WMGetFirstInArray(wapp_list, (void *)appId)
== WANotFound
session.c: WMAddToArray(wapp_list, (void *)appId);
session.c: WMFreeArray(wapp_list);
kix@debian:~/src/wmaker/wmaker-crm/src$
8<
This variable is needed to restore the screen without re-create the
applications structs.
---
src/application.c |4
1 file changed, 4 insertions(+)
diff --git a/src/application.c b/src/application.c
index abe1d2d..6a03775 100644
--- a/src/application.c
+++ b/src/application.c
@@ -143,6 +143,10 @@ WApplication *wApplicationCreate(WWindow * wwin)
create_appicon_for_application(wapp, wwin);
+ /* Save the application in the application list */
+ wapp->next = scr->wapp_list;
+ scr->wapp_list = wapp;
If wapp_list was not set before then wapp->next will contain junk
at this point, no?
Yes. Good point. We should initialize the wapp_list when wmaker starts.
This list is needed to re-position the windows, for example with
XRandR screen change.
We have a different list for appicons. See src->app_icon_list. Is the
same idea.
With XRandR, we should follow the app_icon_list to re-position the
appicons and then paint it (move them). And we should follow the
wapp_list to to the same with the windows.
I didn't found where the app_icon_list is initialized.
Cheers,
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 4/8] Split dock menu creation
Quoting "Carlos R. Mafra" : On Wed, 17 Apr 2013 at 6:37:57 +0000, Rodolfo García Peñas (kix) wrote: Hi Carlos, something is wrong in this patch. Please, don't apply it yet. I was not planning to apply it. I don't think that all that code movement is worth the trouble. We will need some parts of this code to the XRandR too. The XRandR needs split the item creation and the item painting. Cheers, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Move the "Add drawer" option down
IMO, the option "Add drawer" should be moved down in the dock's menu. IMO, the right list sort should be: - Launch - Bring here - Hide - Settings - Dock position - Add drawer - Kill I use sometimes the "Launch" option and now I am adding drawers every time. kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 6/8] Create clip only if needed
Quoting "Carlos R. Mafra" :
On Tue, 16 Apr 2013 at 23:25:10 +0200, "Rodolfo García Peñas (kix)" wrote:
On 16/04/2013 22:06, Carlos R. Mafra wrote:
>> +int wWorkspaceNew(WScreen *scr, Bool with_clip)
>> {
>>WWorkspace *wspace, **list;
>>int i;
>> @@ -102,7 +102,7 @@ int wWorkspaceNew(WScreen *scr)
>>sprintf(wspace->name, _("Workspace %i"),
scr->workspace_count);
>>}
>>
>> - if (!wPreferences.flags.noclip)
>> + if (!wPreferences.flags.noclip && with_clip)
>
>
> This seems redundant.
>
> Why can't you use the noclip flag directly instead of adding the new
> with_clip argument? Ie, if the noclip flag is set then that should be
> equivalent to your !with_clip case.
>
Hi Carlos,
these flags are different.
wPreferences.flag.noclip is used when the user don't want to use the clip.
Then, if the flag is set, the Clip is never used.
So if the user doesn't want the clip you should not create it in the first
place too. So instead of adding an extra parameter to control the creation,
simply use the existing flag to make the decisions. I don't see the need
to add the with_clip argument when you already have a noclip flag.
Brrr, I need improve my english.
This is the current flow:
1. The workspace creates the clip when is restored
2. The clip is removed
3. The Clip is created again if the flag "noclip" is not set.
With the patch, the flow is:
1. The workspace is created, but not the clip, when is restored -> The
with_clip flag is used for that
2. The clip is not removed, because is not created in the step 1
3. The Clip is created if the flag "noclip" is not set. -> We use the
noclip flag for that
Then, only the step 3 creates the Clip.
If the flag noclip is set, without the patch, then, the Clip is never
created in the step 3 (I am not sure if is created in the step 1, I
need check the code).
If we use the flag noclip with the funcionality of with_clip flag, the
flow should be:
1. Set the noclip flag to false
2. The workspace is created, but not the clip, when is restored
(again, I need check if this function test the noclip flag)
3. The clip is not removed, because is not created in the step 1
4. *Restore* the initial value of "noclip", because the user might see
the clip
5. The Clip is created if the flag "noclip" is not set.
When we set the with_clip flag is only for that function flow, but not
for all the wmaker session.
I don't see why these things have to be different. If noclip is set in
WPrefs the user already told wmaker he doesn't want a clip, so the
functions should not create it.
And if the user want the clip? He select the "noclip" to false, then
the clip is created when the workspace is restored, then removed, then
created again...
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
