[PATCH] Small typo with the word attempts
From: Rodolfo García Peñas (kix) k...@kix.es This patch changes the word attemps to attempts in src/dock.c --- src/dock.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/dock.c b/src/dock.c index 902ac2e..14b34f4 100644 --- a/src/dock.c +++ b/src/dock.c @@ -4287,7 +4287,7 @@ static char * findUniqueName(WScreen *scr, const char *instance_basename) } if (i == UNIQUE_NAME_WATCHDOG) - wwarning(Couldn't find a unique name for drawer in %d attemps., i); + wwarning(Couldn't find a unique name for drawer in %d attempts., i); #undef UNIQUE_NAME_WATCHDOG return buffer; -- 1.7.10.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: editing dockapp settings causes crash
On Mon, 09 Sep 2013, Carlos R. Mafra escribió: Thanks for the analysis Rodolfo, but I don't like your patch(es). :-) What do you think about making wIconChangeImageFile() return 'int' and get rid of the True/False and use 0 and 1? Ok, it is a good idea. I will write the patch today. I am a little bit busy (I am on vacactions, and writing wmaker code...). Cheers, kix -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 11/22] New struct wks_nfo
On Thu, 5 Sep 2013 at 21:08:22 +0200, Rodolfo García Peñas (kix) wrote:
From: Rodolfo García Peñas (kix) k...@kix.es
The new struct wks_nfo includes the global information
for the workspaces. All information related with the workspaces
should be included here.
The first variable moved is workspace_name_font, included in this
patch. This variable was included in the screen info, but the
screen and the font used in the workspace name don't have any
relationship.
---
src/defaults.c | 10 +-
src/main.c |4
src/screen.h|2 --
src/workspace.c |9 +
src/workspace.h |4 +++-
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/src/defaults.c b/src/defaults.c
index 02f01a3..67ca62a 100644
--- a/src/defaults.c
+++ b/src/defaults.c
@@ -76,6 +76,7 @@ extern WDDomain *WDWindowMaker;
extern WDDomain *WDWindowAttributes;
extern WDDomain *WDRootMenu;
extern int wScreenCount;
+extern wks_info wks_nfo;
extern WShortKey wKeyBindings[WKBD_LAST];
typedef struct _WDefaultEntry WDefaultEntry;
@@ -2584,15 +2585,14 @@ static int setClipTitleFont(WScreen * scr,
WDefaultEntry * entry, void *tdata, v
return REFRESH_ICON_FONT;
}
-static int setLargeDisplayFont(WScreen * scr, WDefaultEntry * entry, void
*tdata, void *foo)
+static int setLargeDisplayFont(WScreen *scr, WDefaultEntry *entry, void
*tdata, void *foo)
{
WMFont *font = tdata;
- if (scr-workspace_name_font) {
- WMReleaseFont(scr-workspace_name_font);
- }
+ if (wks_nfo.workspace_name_font)
+ WMReleaseFont(wks_nfo.workspace_name_font);
- scr-workspace_name_font = font;
+ wks_nfo.workspace_name_font = font;
return 0;
}
diff --git a/src/main.c b/src/main.c
index 69a68e2..18f6002 100644
--- a/src/main.c
+++ b/src/main.c
@@ -56,6 +56,7 @@
#include dialog.h
#include main.h
#include monitor.h
+#include workspace.h
#include WINGs/WUtil.h
@@ -129,6 +130,9 @@ Atom _XA_WM_IGNORE_FOCUS_EVENTS;
/* cursors */
Cursor wCursor[WCUR_LAST];
+/* Workspace information */
+wks_info wks_nfo;
This patch is a great idea, but I feel the naming convention is
on the borderline of too cryptic. Perhaps it's just me, but
wks_nfo
is a bit disturbing and distracts a bit while reading the code.
--- a/src/workspace.h
+++ b/src/workspace.h
@@ -22,7 +22,9 @@
#ifndef WMWORKSPACE_H_
#define WMWORKSPACE_H_
-
+typedef struct wks_info {
+ WMFont *workspace_name_font;
+} wks_info;
typedef struct WWorkspace {
char *name;
Perhaps 'typedef WWorkspace_info' would make
more sense? Note the extra W like in WWorkspace -- I think
it is good to have patterns like this.
And then we could have
WWorkspace_info wks_info;
instead of
wks_info wks_nfo;
May I suggest you to rename this? Perhaps it makes more sense to
redo your last series altogether. Remove the troublesome patch about
True vs False and do the above renaming.
Since it's on #next, I can freely substitute the old series by the new
one with rebase.
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker 0.95.5
On Mon, 09 Sep 2013, Christian escribió: Am 09.09.2013 12:25, schrieb Rodolfo García Peñas (kix): I will wait for the official version number tgz too for the Debian package. I am very new to debian packaging and you seem to be familiar with this stuff. Can you give me some tips where to start and what I need ? Sure, the main ideas: - You need the upstream source, but you never change it when packaging - You need a debian folder in the upstream source (I post the changes in the current next branch). Basic steps: 1. Download the source. You can choose, download the current git branch (master or next, with git clone), the current git snapshot (like the link that Carlos post yesterday) or the official .tgz file (John upload it). 2. Make the original tgz. You need it if you are not using the official tgz file or the git snapshot file (in this case, rename it). The original tgz file has this syntax: wmaker_version.orig.tar.gz (pe. wmaker_0.95.5.orig.tar.gz). This file is place in the same folder where you have the root folder of the source: kix@osaka:~/wmaker$ ls wmaker-0.95.5 wmaker_0.95.5.orig.tar.gz 3. Uncompress the orig file. You will get the wmaker folder and the wmaker_*orig.tar.gz file. The wmaker folder name doesn't matter, could be wmaker, wmaker-crm, wmaker-version... 4. Make the debian changes. This is a little bit long. Probably you should read the Debian manuals for packaging. I will write some lines with the basic changes: 4.1. Update the debian/changelog file. You can use the dch command. Then, you will create a new debian package version (same that the file name version). You need include all the changes in that file. The example for some current changes: wmaker (0.95.5-1) unstable; urgency=low * New upstream version 0.95.5. - New WUtil library version 3. - Updated debian/control file, replacing libwutil2 with libwutil3 Included Replaces: and Breaks: fields. - Files moved in debian folder: - libwutil2.changelog-upstream - libwutil3.changelog-upstream - libwutil2.install - libwutil3.install - Removed file libwutil2.symbols - New file libwutil3.symbols - Updated symbols in libwings2.symbols - New patch 55_typo.diff to solve a small typo in src/dock.c. * Build-Depends: libtiff5-dev in packages wmaker and libwraster3-dev, since libtiff-dev introduces dependency to libtiff4 which is in oldlibs. * ... 4.2. Update the debian files. Now the files are fine. I did a lot of changes in previous versions, and now, changes are small. But the next package version is a little bit hard, because it has changes about the shlibs of libwutil3 and libwutil2.symbols. The shlibs are complex, but the main idea is build the package and apply the diff patch. 4.3. Other important thing is changes on the source code. You need create a debian/patches/patch. This file is a diff for the current source. You should create it using quilt. I am working to remove all differences between upstream and debian, but not always is possible. 5. Built the source :-) Go to the upstream source root folder. (Remove the .git* files if you are using git and the file debian/nightly_build.sh), and run dpkg-buildpackage -uc -us -tc -sa. You will get the new package files if all is ok. If you have more questions, don't hesitate in ask me. Please, don't upload the changes to Debian directly (don't make NMU), because I am working in the package. I use the official tgz file to upload the changes to Debian. This file is a make dist of the current source. John uploads it. I download this file, apply the changes and then upload the new package to Debian (unstable) and send the changes to the git. I don't send many changes in debian git's folder to avoid disturb Carlos. kix. Do you know openSuSE buildservice ? Nooop. I use Debian, is the best ;-) Thank you You are welcome! kix -- Christian - Please do not 'CC' me on list mails. Just reply to the list :) Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.info. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 11/22] New struct wks_nfo
On Mon, 9 Sep 2013 at 18:31:52 +0200, Rodolfo García Peñas wrote: Ok, I will try to do it. I don't have problems to change the names, the important thing is the idea of using a workspace struct split of the WScreen struct. I completely agree with the general direction here. It makes a lot of sense. But when I read the code for the first time I noticed the wks_nfo name but I didn't want to complain just because of a missing i :-) But after the problem with the other patch was found I thought I should bring this up too. So the series can be redone without the buggy patch and with a (hopefully better) new naming convention. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 11/22] New struct wks_nfo
On Mon, 09 Sep 2013, Carlos R. Mafra escribió:
On Thu, 5 Sep 2013 at 21:08:22 +0200, Rodolfo García Peñas (kix) wrote:
From: Rodolfo García Peñas (kix) k...@kix.es
The new struct wks_nfo includes the global information
for the workspaces. All information related with the workspaces
should be included here.
The first variable moved is workspace_name_font, included in this
patch. This variable was included in the screen info, but the
screen and the font used in the workspace name don't have any
relationship.
---
src/defaults.c | 10 +-
src/main.c |4
src/screen.h|2 --
src/workspace.c |9 +
src/workspace.h |4 +++-
5 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/src/defaults.c b/src/defaults.c
index 02f01a3..67ca62a 100644
--- a/src/defaults.c
+++ b/src/defaults.c
@@ -76,6 +76,7 @@ extern WDDomain *WDWindowMaker;
extern WDDomain *WDWindowAttributes;
extern WDDomain *WDRootMenu;
extern int wScreenCount;
+extern wks_info wks_nfo;
extern WShortKey wKeyBindings[WKBD_LAST];
typedef struct _WDefaultEntry WDefaultEntry;
@@ -2584,15 +2585,14 @@ static int setClipTitleFont(WScreen * scr,
WDefaultEntry * entry, void *tdata, v
return REFRESH_ICON_FONT;
}
-static int setLargeDisplayFont(WScreen * scr, WDefaultEntry * entry, void
*tdata, void *foo)
+static int setLargeDisplayFont(WScreen *scr, WDefaultEntry *entry, void
*tdata, void *foo)
{
WMFont *font = tdata;
- if (scr-workspace_name_font) {
- WMReleaseFont(scr-workspace_name_font);
- }
+ if (wks_nfo.workspace_name_font)
+ WMReleaseFont(wks_nfo.workspace_name_font);
- scr-workspace_name_font = font;
+ wks_nfo.workspace_name_font = font;
return 0;
}
diff --git a/src/main.c b/src/main.c
index 69a68e2..18f6002 100644
--- a/src/main.c
+++ b/src/main.c
@@ -56,6 +56,7 @@
#include dialog.h
#include main.h
#include monitor.h
+#include workspace.h
#include WINGs/WUtil.h
@@ -129,6 +130,9 @@ Atom _XA_WM_IGNORE_FOCUS_EVENTS;
/* cursors */
Cursor wCursor[WCUR_LAST];
+/* Workspace information */
+wks_info wks_nfo;
This patch is a great idea, but I feel the naming convention is
on the borderline of too cryptic. Perhaps it's just me, but
wks_nfo
is a bit disturbing and distracts a bit while reading the code.
--- a/src/workspace.h
+++ b/src/workspace.h
@@ -22,7 +22,9 @@
#ifndef WMWORKSPACE_H_
#define WMWORKSPACE_H_
-
+typedef struct wks_info {
+ WMFont *workspace_name_font;
+} wks_info;
typedef struct WWorkspace {
char *name;
Perhaps 'typedef WWorkspace_info' would make
more sense? Note the extra W like in WWorkspace -- I think
it is good to have patterns like this.
And then we could have
WWorkspace_info wks_info;
instead of
wks_info wks_nfo;
May I suggest you to rename this? Perhaps it makes more sense to
redo your last series altogether. Remove the troublesome patch about
True vs False and do the above renaming.
Since it's on #next, I can freely substitute the old series by the new
one with rebase.
Ok, I will try to do it. I don't have problems to change the names, the
important thing is the idea of using a workspace struct split of the WScreen
struct.
Take a look about the idea of using two different structs. wks_info contains
the common info for all workspaces, and workspace, with the info for the
current workspace (we have multiple workspaces, so we have multiple workspace
structs). Differences:
- We have only one wks_info struct.
- We have multiple workspace structs. Is an array of workspaces.
- The array of workspaces is in wks_info struct.
- The Dock, Clip and Drawers are 'per-workspace', so are included in the
workspace variable.
- The workspace_count or the workspace menu is the same for all workspaces, so
re in the wks_info.
- The background could be different in every workspace, but currently, is set
using the setbg tool and we cannot use it in the workspace struct, only in the
wks_info struct.
Thanks for your comments. I will write the changes this evening.
kix
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 11/22] New struct wks_nfo
On Mon, 09 Sep 2013, BALATON Zoltan escribió: On Mon, 9 Sep 2013, Rodolfo García Peñas wrote: - The Dock, Clip and Drawers are 'per-workspace', so are included in the workspace variable. I don't get this. The Dock is the same for all workplaces but the clip isn't (at least the app icons attached to it are different on differrent work spaces). Why does it make sense to have a global clip instead of per workspace ones? I haven't tried drawers yet but I expect them to be different on different work spaces too. I haven't looked at the code, just trying to understand it conceptually. Hi Zoltan, yes, I had this idea, only one Dock, multiple Clips. Currently, only the clip image is shared between the different Clips. But is not true, see below. My aim is that the Clip, Drawer and the Dock will be the same internal object, but if it is the Clip, then it has some properties active and if it is the Dock, others. Same for the Drawers. Then the code is easier. Ok, continue. The last week I asked about why in the screen.c file, some code initilize more than one Dock. The reply was about the possibility of having multiple monitors, with different workspaces, and then different Docks. Then, the code will be something like, if we have one or more workspaces, but all uses the same Dock, no problem, we have one Dock object in the Workspace[0] and the other workspaces has pointers to that Dock. If we have multiple workspaces, with different Docks, then, we have different objects. I don't know if we want this, but is the current behaviour. I have one patch here with the Dock struct moved to wks_nfo (not to the workspace struct), so, this patch only creates one Dock. I tested it here without problems, with multiple monitors and XRandR, without problems. But, we lost the multiple docks for multiple workspaces. I did this patch because currently the code in the wmaker start process binds the dock to the screen, not to the workspace, and I need rewrite some code to change the wmaker start process to create the screen, create the workspaces with the docks, and then bind them. I cannot do that yet, because I have problems with the dock menu (they need the WScreen struct, and I need indpendency with the screen to do it). Best regards, kix Regards, BALATON Zoltan -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 11/22] New struct wks_nfo
OK, it's getting clearer now. On Mon, 9 Sep 2013, Rodolfo García Peñas wrote: My aim is that the Clip, Drawer and the Dock will be the same internal object, but if it is the Clip, then it has some properties active and if it is the Dock, others. Same for the Drawers. Then the code is easier. So you want one single class that can be configured to behave like the Dock or the Clip or a Drawer? Wouldn't it be too complicated? Wouldn't it be a better object oriented design to have the common code in an abstract class and have the three specialised objects inherit from it and add/override what is needed? The last week I asked about why in the screen.c file, some code initilize more than one Dock. The reply was about the possibility of having multiple monitors, with different workspaces, and then different Docks. Maybe in a multiheaded X config with different screens. I never tried to run Window Maker on such a config so I don't know about that. Then, the code will be something like, if we have one or more workspaces, but all uses the same Dock, no problem, we have one Dock object in the Workspace[0] and the other workspaces has pointers to that Dock. If we have multiple workspaces, with different Docks, then, we have different objects. I think you mean instances of the above classes and want to share a single instance between multiple work spaces. Then I understand this. because currently the code in the wmaker start process binds the dock to the screen, not to the workspace, and I need rewrite some code to change the wmaker start process to create the screen, create the workspaces with the docks, and then bind them. I cannot do that yet, because I have problems with the dock menu (they need the WScreen struct, and I need indpendency with the screen to do it). Can't comment on this. But I just noticed that the Dock menu has an Add a drawer item but the Clip menu doesn't. Is there a way to add a drawer to the Clip? Regards, BALATON Zoltan
Re: Window Maker 0.95.5
I use the official tgz file to upload the changes to Debian. This file is a make dist of the current source. John uploads it. I download this file, apply the changes and then upload the new package to Debian (unstable) and send the changes to the git. I don't send many changes in debian git's folder to avoid disturb Carlos. kix. thanks for your explanations. one question left. When you build the pkg, then you build it in a chroot env or in the same env you are working ? Do you know openSuSE buildservice ? Nooop. I use Debian, is the best ;-) Hehe, you misunderstood me. 'openSUSE buildservice' is a service to build binary packages from sources. https://build.opensuse.org/ not only for openSUSE, not only for RPM packages, but also debian/ubuntu packages. I think we could bundle our effort in providing binary packages. perhaps you should have a look at it. Even if you think debian is best ;) Cheers -- Christian - Please do not 'CC' me on list mails. Just reply to the list :) Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Window Maker 0.95.5
On Mon, 09 Sep 2013, Christian escribió: I use the official tgz file to upload the changes to Debian. This file is a make dist of the current source. John uploads it. I download this file, apply the changes and then upload the new package to Debian (unstable) and send the changes to the git. I don't send many changes in debian git's folder to avoid disturb Carlos. kix. thanks for your explanations. one question left. When you build the pkg, then you build it in a chroot env or in the same env you are working ? In a chroot environment and in a clear environment for building. See pbuilder. Do you know openSuSE buildservice ? Nooop. I use Debian, is the best ;-) Hehe, you misunderstood me. 'openSUSE buildservice' is a service to build binary packages from sources. https://build.opensuse.org/ not only for openSUSE, not only for RPM packages, but also debian/ubuntu packages. I think we could bundle our effort in providing binary packages. perhaps you should have a look at it. Even if you think debian is best ;) :-) Yes, I saw that page some time ago, somebody talk me about it. I run wmaker Debian packages in some machines, and wmaker upstream in others (for devel wmaker upstream). The main difference is the paths (/usr vs. /usr/local) and then the configuration folders (/usr/local/etc... vs. /etc/GNUstep). We should work in this direction, because if upstream = distro, problem solved :-) Cheers, kix Cheers -- Christian - Please do not 'CC' me on list mails. Just reply to the list :) Der ultimative shop für Sportbekleidung und Zubehör http://www.sc24.de -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
